DEV Community

Ben Halpern
Ben Halpern Subscriber

Posted on

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

What wisdom are newbies missing in your experience?

Top comments (21)

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

That it's all about the technical details. They are important, but getting the details perfect won't matter if the business problem is misunderstood. You'll build a solution to a problem they don't have and create new problems. I did that more than once in my career.

I good indicator that there is a misunderstanding is when you get into a coding conundrum. Meaning you had to solve a technical problem that doesn't make sense to you. It kinda gives you a weird feeling like something is missing. Learn to listen to that and ask questions until you figure out what's missing.

Collapse
 
cerchie profile image
Lucia Cerchie • Edited

I like how you said "It kinda gives you a weird feeling like something is missing." When I get that feeling I have step back and ask about the context because my big picture is partial.

Collapse
 
uzair004 profile image
Muhammad Uzair

That's true, I found myself asking so many questions even explaining how we are going to solve a problem, But I found myself bit low because of so many questions I ask, it's like in every standup meeting I keep asking many questions and counter client in demand in many ways, It kinda "make me feel like if i have problem for every solution". Thinking about all scenarios before starting is time consuming & stressing as well.

Collapse
 
kspeakman profile image
Kasey Speakman

That's a good point Muhammad. The other part of knowing that dev is not only about the technical details is using the same terminology as the customer/user/stakeholder. Early in my career I insisted the user learn my language about fields and strings and technical things. But I found the most success learning to speak the user's terms. So they can correct me when I use them wrongly, and then I learn to see from their perspective. Even practice what they do if I can. Then when I code something I'm thinking of solving their problem more than the technical. Even if it is a little off target it's close enough that it can be fixed without large refactors. And it doesn't accrue as much tech debt in general.

Collapse
 
jmplourde profile image
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.

Collapse
 
stephanie profile image
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.

Collapse
 
murtuzaalisurti profile image
Murtuzaali Surti
  1. I would suggest no need to cram the syntax! Just focus on logic and the right technology!

  2. Stay away from tutorial hell and focus on building projects on your own!

Collapse
 
oliviadavis593 profile image
Olivia Davis

I feel the 2nd part so heavy! I'm literally 2 years in this field and I'm still studying via courses almost everyday :(

Collapse
 
aileenr profile image
Aileen Rae • Edited

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.

Collapse
 
strafer14 profile image
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".

Collapse
 
xarop_pa_toss profile image
Ricardo Giro

Giving the reverse view as newbie myself that learned programming at school and only now, many years later, got back into it.
Go out of your way to learn to test your code. It may not feel as fun as just writing out solutions to problems but if the user can break your code with something simple like a type error, then you aren't done yet.

Embrace the testing, the error handling and the best practices. Always have in the back of your head that your code will be read by other people and plan for that. Comment stuff that isn't totally obvious, follow naming conventions, etc.
This is harder than it looks at the start, but I feel is super important for the future.

Hey nice topic :)

Collapse
 
sirseanofloxley profile image
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.

Collapse
 
matthewbdaly profile image
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?"

Collapse
 
cchana profile image
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.

Collapse
 
taijidude profile image
taijidude • Edited

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.