What wisdom are newbies missing in your experience?
For further actions, you may consider blocking this person and/or reporting abuse
What wisdom are newbies missing in your experience?
For further actions, you may consider blocking this person and/or reporting abuse
Sukhpinder Singh -
Lucas Chitolina -
Chris Jarvis -
Oliver Bennet -
Top comments (21)
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.
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.
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.
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.
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.
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.
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!
I feel the 2nd part so heavy! I'm literally 2 years in this field and I'm still studying via courses almost everyday :(
I'm only a newbie to senior level myself, but the biggest paradigm shifts in my understanding of this job so far have been:
Edit for typos.
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".
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 :)
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.
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:
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?"
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.
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.