Ben Halpern

Posted on Apr 21, 2022

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

#discuss #watercooler

What wisdom are newbies missing in your experience?

Top comments (21)

Kasey Speakman • Apr 21 '22 • 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.

Lucia Cerchie • Apr 21 '22 • 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.

Muhammad Uzair • Apr 21 '22

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.

Kasey Speakman • Apr 22 '22

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.

Jean-Michel Plourde • Apr 21 '22

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 • Apr 22 '22

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.

Murtuzaali Surti • Apr 21 '22

I would suggest no need to cram the syntax! Just focus on logic and the right technology!
Stay away from tutorial hell and focus on building projects on your own!

Olivia Davis • Apr 23 '22

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

Aileen Rae • Apr 22 '22 • 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:

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.
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.
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.
Communication, empathy and other so-called "soft skills" are core skills for being an effective developer.

Edit for typos.

Michael Ostrovsky • Apr 22 '22

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".

Ricardo Giro • Apr 21 '22

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 :)

Sean Allin Newell • Apr 21 '22

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.

Matthew Daly • Apr 22 '22

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?"

Charanjit Chana • Apr 23 '22

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.