What misconceptions do early-career devs have about this work?

What wisdom are newbies missing in your experience?

Comments

[Martin Wheeler]

That asking for help is bad or makes you look like an inexperienced developer. This was one of my biggest weaknesses but now I really enjoy connecting with other Devs. It's a great opportunity for growth and can build stronger relationships 🙂

[Andrew Baisden]

This!

[Marcelloh]

It's okay when others say bad things about the brilliant stuff you just created.
I think I will write an article about it.

I just did :-)

dev.to/marcello_h/your-code-stinks...

[Benny Powers 🇮🇱🇨🇦]

That it's wise to invest in React

[Charanjit Chana]

There’s one path to follow.

I never thought I’d be managing teams when I first started out and yet here I am. Others I’ve worked with (older and younger) continue to code and there’s absolutely nothing wrong with that. Different paths take you different ways, some may even go back but it’s about what works for you.

[Matthew Daly]

That framework performance benchmarks bear any significant relation with the performance of an actual application built with those frameworks.

The actual things that cause an application to be slow are things like these:

• N+1 database queries
• Poor database schema design
• Missing indexes
• Failure to set appropriate headers
• Failure to cache data when appropriate
• Loading unnecessary assets

And these are problems that can occur with any framework. Yet people are always posting queries on forums about "Which framework should I use for high performance?"

[Aileen Rae]

I'm only a newbie to senior level myself, but the biggest paradigm shifts in my understanding of this job so far have been:

1. Idiot-proof code is 1000% better than "smart" code. Developers spend more time reading code than writing it, so it's in everyone's best interest to make that reading as easy as possible. This can often mean violating principles like DRY.
2. Related to the above: Best practices? They're not gospel. They're context-dependent guidelines. The most "expert" developers I've met understand their benefits, drawbacks, and know when other concerns take precedence.
3. Knowing how to parse out business problems from client/non-tech people and solve them in a high-level, abstract way is a more important skill than perfecting the nitty-gritty of writing code.
4. Communication, empathy and other so-called "soft skills" are core skills for being an effective developer.

Edit for typos.

[Michael Ostrovsky]

A common misconception I meet with people in their earlier stage is that they tend to think they are measured on their technical prowess which causes them to complicate things way more than necessary. I guess a lot of people think that the best developers think of the "smartest" solutions where in reality the art is to understand your code is gonna be read many times by different people and so a straight forward understandable solution should be used wherever appropriate even if it isn't "cutting-edge" or "smart".

[Sean Allin Newell]

A lot of junior/mid levels misinterpret senior role requirements as just more activity and work, rather than domain expertise, business results, and team performance.

[Jean-Michel Plourde]

It's a cliché that developer are anti-social creatures, but the reality is communication is at the center of everything. Knowing how to communicate, when and to who is really important so projects can stay on track.

[Stephanie Handsteiner]

100%, learnt that the hard way.
Knowing how, when, and where to communicate is important, it's easier to steer in another direction when you know early than afterwards when it's too late.

Technical skills are important too, of course, but they're, if lacking, easier to learn than right communication.

[taijidude]

That human communicating will just take care of itself and not really understanding how much a good manager can be worth.

Oh and thinking that you are done learning when the job starts. That puzzels me.