Quickfire Discussion: I'm a Junior Developer, tell me your top 3 pieces of advice.

github logo ・1 min read

Quickfire Discussion: I'm a Junior Developer, tell me your top 3 pieces of advice.

What did you wish you knew when you were a Junior Developer?

What would you tell current Junior Developers?

etc

twitter logo DISCUSS (22)
markdown guide
 

Posse up.

Everyone tells you to attend all the meetups, but sometimes that's difficult and intimidating when you're new and don't know a lot of the people at the meetups. Befriend other junior devs around town, and you'll find meetups become more enjoyable. (Bonus: You're building a strong network with future senior devs!)

Keep healthy.

Get sun, move around, laugh freely (even laughing meditation does wonders). You've got a long life ahead of you, so please care for yourself.

Work on a long-running project.

Toy apps are tempting, and you should indulge a bit. But make sure to set aside some time for a larger project, or just a project that takes longer to finish. You'll find such projects work different "muscles", and they'll contain opportunities for learning that smaller projects won't. Maybe partner up with a friend or recent meetup acquaintance.

 

BIG + 1 to Work on a long-running project this is exactly what pushed me to start dev.to and stay motivated to grow it.

 

Bravo, @Sumeet!

You are your Reputation. Act Accordingly.

Make yourself known in your organization for delivering quality stuff, on-time, that's easy to sustain in production. Be the kind of guy that when someone comes to a dev manager in a crisis and says, "Andrew's available...can he help you out?" They immediately think, "THANK GOD!"

By the same token, never sacrifice your reputation for a single "win". Your rep is not worth a single account, single production deploy, or single code commit. Don't climb over somebody else's back to win. Give credit to others. Cover for them. Be someone who earns their trust, genuinely.

It's not what you know. It's who knows what you know.

Follow-on to the above. Put yourself out there enough so that whoever "they" are, "they" have confidence in you. I once had a developer I was mentoring that I pushed forward for promotion, and my director said simply, "I don't know this person. That's a problem." For a technical person, that's irrational, but I've found it to be true.

Set firm boundaries for yourself

I'm a person who didn't have boundaries. I worked too much on things that eventually ended up in the bargain bin of Office Depot. For what? It's a miracle I still have a family.

Do better. Cultivate saying "No" and setting expectations in a way that's professional.

 
 

Get curious

Have side projects of varying sizes / timeframes. Read a lot (books, more dev.to articles, other blogs... Twitter is your friend). Listen to podcasts. Experiment with new languages / frameworks / tools. Contribute to open source. Whatever 'curiosity' looks like for you, do it. Don't leave your craft at work.

That being said...

Know when to walk away

Don't hesitate to ditch a problem that's seriously frustrating you. Chances are you'll come back tomorrow and solve it in 5 minutes. Don't sacrifice the long-term love of your craft and drive yourself nuts over short-term bugs. To quote Rework, "ASAP is poison."

Speaking of your craft...

Software engineering is a craft. Treat it as such.

Learn to write Clean Code. Use TDD. Get really comfortable with the tools you use every day. You'll save yourself and your team loads of time and effort, and generally feel like a bad@$$ knowing that you're good at your job.

It's smart to ask questions like this as a junior dev, when your habits are still relatively malleable!

 

Can't recommend Clean Code enough. It changed my way of thinking about code so much!

 

Think longterm

Progress is up and down in this career. Don't pay attention to the short intervals. Lonterm gains are clearer.

Avoid FOMO

Fear of missing out on different technologies can be paralyzing. Have fun with what you're currently into and realize you can catch up later with the rest.

Don't make apps for your friends and family

Seriously. Everyone wants you to partner with them on something. Try to manage their expectations.

 

Thanks for making this post!

All the responses are πŸ”₯πŸ’ͺπŸ”₯

 
  • Don't worry, nobody knows what they are doing
  • Ask a lot of questions.
  • Be honest, no matter what
 

Just this: read voraciously. Read about everything. Read whatever you can find. Read on the job. Read at home. Read waaayyyyy more than you need to in order to solve a given problem. Read until you know the right way to do the thing. Your market value will rise exponentially.

Ask your company to buy you some books. I always recommend Code Complete, but also get some books on the languages or technologies you're using.

If your company won't buy you books or doesn't let you spend a few hours on the clock every week reading in order to sharpen your skills, quit. Per hour, working increases your value by fractions of a cent; reading increases your value by dollars.

 

1. Your real job

2. A business (aka workplace)

business

Original tweet: twitter.com/JoseGonz321/status/917...

3. Learn personal finance

  • Don't impress yourself with how much you earn, impress yourself with how much you keep.

  • Frugality is king whether you are making $50K or $100k+

  • As you become more senior, the money will be there. But the salary ceiling is very real. Find out what you want to do: (consulting, service, product?) as you progress in your adventure.

  • Invest

 
  1. Learn SOLID Principles and read The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin

  2. Always focus on improving. Improve you knowledge, skills, experience, soft skills. The more you learn, the more you earn #HoskWisdom

  3. You are responsible for your career. You must drive it and know where you are going. Know what your dream job is, know what your next role is and start learning heading in that direction.

Longer version can be found on my blog for Dynamics devepers
crmbusiness.wordpress.com/2017/09/...

 
  • The field of programming is so huge that it's easy to feel like everyone else is smarter than you because they know so much that you don't. Different people have different areas of expertise. You've probably solved problems of had experiences they haven't as well.

  • Success means different things to different people. Not everyone wants to become a manager, an entrepreneur, ... And that's perfectly fine.

  • This may not seem related to programming, but it is: When you're physically unwell, you go to the doctor. Don't be affraid to do the same thing for your mind.

 

Debug your code

I've taught basic and intermediate programming to students and co-workers, and one recurring behavior is that people often forget the debugger is there to help. Be careful with endless trials and errors when troubleshooting bugs in your code, but instead take some time, debug it and understand the flow it's taking and where are the gaps.

Is programming a job or a career for you?

It will take a while for you to figure this out, but will help you realize where do you want/need to put your focus on. If you really enjoy and want to improve your programming skills, do not rely solely on what your job has to offer you challenge-wise. Study and practice on your own, keep reading about what are the current trends and why, and if you're up to, build some side projects.

Refactor always

On the first few years of your career, you will often join teams that are rebuilding something, often a redesign of an old, legacy system. Your new system is cool and shiny, and everyone loves it. After a while, in exchange of productivity, people might start taking shortcuts to deliver things faster; New members might be assigned tasks which they have no idea where to start and will deliver code outside your standards; Also, if you have plenty of unit tests, which are there to help, you might be intimidated when you think about refactoring something that's there for a while, and heavily tested: if you refactor that, you'll have to review/rewrite so many tests! After a while - usually after the team changed so much it has no faces from the original team, they realize that - ta-da! - they got a new legacy system, and the cycle repeats. To an extent, much of this could've been avoided if the team was committed to quality and were not afraid of refactoring code. Well-written, flexible and secure code can accommodate design changes and be submitted to new business needs.

 

Write Code Every Day

Dancer is dancing, pianist is playing on the piano, programmer is writing code. Every day.

Learn How Computers Work

If you don't know how computers work, you're not "authorized" to write programs. Don't forget, you don't just use computers, you are adding your part to a system. The best way to learn how computers work is to learn assembly. You don't have to learn x86-64, you may choose a vintage platform, e.g. 8086 DOS, C64 etc., they're simpler and provide more fun.

Create Pet Products

At the work, you're a small cog in a big machine. It's okay, it's very profitable to know how to be a part of a big project, how to work together with many people, know tools and methodics. But at home, you are alone, and you should do your pet projects as if they were products. Use version control (GitHub - share), write unit/integration tests, write documents (how to compile, how the code is organized etc.), write manual (for users), create a small website (marketing), make a real product.

 

I've been in this career for 30 years. I've done poorly with my #1 suggestion although I'm improving, OK with #2 and I've done pretty well with #3.

(1) Healthy eating and exercise habits - It's easy to develop a "programmer gut". Make sure you eat right and in moderation and take time away from the screen to exercise.

(2) Learn to tolerate BS. Don't let it rattle you when the project you just spent 6 months on is canceled, your company shuts down or other unfortunate events happen. Also, managers, other developers and project sponsors can be total jerks at times. Learn to roll with the punches because there always will be a punches, usually a lot of them. Have an exit strategy at all times just in case things go bad.

(3) Always Be Coding. Programming requires constant learning and the best way to learn is to find something new to code. Don't let yourself stagnate in a position or in a programming language.

 

Read other people code (there are a lot of code out there this days) read specially in the areas that you like.

Have a purpose to learn something, like do a usefull app, or make a lib or something.

 
  1. Have discipline;
  2. Read the Documentation;
  3. Forget tools, patterns, languages and frameworks: They are always changing. Focus more on concepts. Knowing the concepts and theories (and putting in practice, of course) changes EVERYTHING.
 

Try things out standalone before integrate them in an existing code base.

Github is more important than Stackoverflow, be because the code always tells the truth.

Don't sweat that you take longer to learn than others, there will always be people who start learning later than you.

 

I've given a talk (video, slides) on this very subject.

Here are my top three pieces of advice for a junior developer:

Embrace learning

Always seek to improve

Be patient

 

All the good advice were already taken 🀠

Focus
There is too much noise out there, especially in the web dev area the ecosystem is so large that it's hard to find a direction. Keep evolving but master a skill/library before moving to another one, the devil is in the details and it takes a time to get there (reaching the limitations of a system, process, framework, language etc).

Steal the craftsmanship
Having a master or seniors around you will boost your career, if not find ones or quit your job, no junior should work alone on a project, is a loss-loss situation.

Like any physical craft, you should observe the senior practitioners, example if you are a web dev you can see a live/coding/panel with Dan Abramov and see first hand how a couple of technologies can boost your productivity 1000%.

Don't compromise (too much)
There is a fine line which you'll soon grasp, between being a professional and just a "worker that does tasks". If you work in a technical Env you're lucky, the guys in charge of the "tasks" know about and appreciate software methodologies (like automatic testing and post mortem team meetings to name a few), if not you have to struggle with the bussiness managers, trying everyday to improve your workflows.

You will soon learn how and when to say NO, sometimes what is good for you and your future or your project is not what the managers ask of you (basic example work overtime, apply dark patterns etc).

 

Ask, ask, ask
Don't be afraid to ask, there's no such thing as stupid or trivial questions. The more you ask, the more you learn how to do the right questions. And asking the right questions is a good way to show that you care about what you are doing, and that you are growing in the right direction.

Give back
Share your knowledge with others. Don't be scared to share an article or a peace of code with an architect. Try to help other developers to solve problems. Share your ideas, thoughts, concerns.

It's a marathon, not a sprint
Don't rush, be consistent, become a reliable member of a team, keep learning. Master your tools and your sources of information. You will find yourself in situations of stress and you need to learn how to handle it to avoid burnout and frustration.

Classic DEV Post from May 31

Presentation Tips for Technical Talks

Presentation Tips for Technical Talks

Andrew Smith profile image
Developer specialising in web development and mobile app development, with a keen interest in JavaScript technologies, cross-platform & native mobile application development and Dev-Ops.

DEV is visited by over 2 million software developers per month. All are welcome to publish here or simply read great content.

Get Started