Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signs of an Immature Software Developer

pragmaticsoftwareengineering.com

Post reply on HN
Print view View original

81–90 of 100 posts

Re: Signs of an Immature Software Developer

#81

Post by ipaddr »

runawaybottle wrote: post #17
goto11 wrote: post #6

I take issue with point 4 "Rejecting of Best Practices". The article states "Simply put, best practices are non negotiable.". Problem is, "best practices" is large body of rules-of-thumb which are almost always context dependent and often contradictory. Often they lead to worse code overall when applied outside of the relevant context. So I would reformulate as: Only reject a "best practice" if you understand why it…

From my experience, it is usually the expert beginner developer that takes up religious ‘best practices’ discipline. This is roughly around the time they are about to get over the plateau and hit 6-7 years of experience. The identity begins to attach to things that fit that timeline, as in, ‘I am roughly here and therefore based on how I see myself, I should be aligned to what I perceive my identity to be’. This real…

I noticed this as well with myself and others. At 5 years you become an expert in whatever stack you choose. Whatever best practice you've adopted becomes religion. It isn't until year 6 or 7 or 8 when you start realizing you know less than you thought. By 20 years realize you know nothing and you have reached developer enlightment.

Coming to terms with the business side is the first step.

Having your best practises or framework mocked by the next generation of zealots is part of the process. Patterns you know and love become anti-patterns only to return in a distance future in some limited formed with great fanfaire.

Letting go and a realizing your project / patterns will get hijacked by the business side, other developers and often enough pms is freeing.

Re: Signs of an Immature Software Developer

#82

Post by Netcob »

minimaul wrote: post #74
tiddles wrote: post #25

Earlier quoted context omitted.

I’ve come across junior colleagues who latch on to some "best practice" that they read/heard about, then preach it to anyone who will listen and aggressively debate it to death, instead of actually getting any work done. The solution is to ignore these "my thing is objectively better than yours in 100% of cases" debates - choose the pattern/design/paradigm/thing with the least compromises and do something productive…

+1 For the juniors on my team, the next question I always ask after the answer "it's best practice" is always "why is it best practice?" It's fundamentally important to understand why something is best practice, so that you know when it is not the best course of action.

Seniors can make the same mistake - I had one literally senior colleague argue that he's been coding for decades longer than I have (I was only coding for ~15 years at the time) and that I should just do as he says, but would not tell me why, or how that applied to the situation.

Re: Signs of an Immature Software Developer

#83

Post by mysterydip »

agumonkey wrote: post #47
tiddles wrote: post #25

Earlier quoted context omitted.

I’ve come across junior colleagues who latch on to some "best practice" that they read/heard about, then preach it to anyone who will listen and aggressively debate it to death, instead of actually getting any work done. The solution is to ignore these "my thing is objectively better than yours in 100% of cases" debates - choose the pattern/design/paradigm/thing with the least compromises and do something productive…

There should be a rule 0: work, don't talk. Usually when people are focused on working and working together fast, the converge on pragmatic efficient solutions. Of course 'together' is subtle here ..

"less talk, more rock" is how one of my colleagues put it.

Re: Signs of an Immature Software Developer

#84

Post by GVIrish »

ratww wrote: post #9

> Simply put, best practices are non negotiable This here is a sign of immaturity. Following Best Practices to the letter without knowing why is fine if you're a student or a junior developer, or if your work is not much off the beaten path. But as soon as you're doing anything more complicated than stringing libraries together you have to know what you're doing and why you're doing it. You have to know the tradeoffs…

The way I would state it is that you need to understand the tradeoffs of given best practices and whether those tradeoffs justify implementing those best practices on your project. It also gets into what best practices should be prioritized over others and on what timeline.

Re: Signs of an Immature Software Developer

#85

Post by bhntr3 »

goto11 wrote: post #6

I take issue with point 4 "Rejecting of Best Practices". The article states "Simply put, best practices are non negotiable.". Problem is, "best practices" is large body of rules-of-thumb which are almost always context dependent and often contradictory. Often they lead to worse code overall when applied outside of the relevant context. So I would reformulate as: Only reject a "best practice" if you understand why it…

Maturity (or seniority) is a form of growth and it has stages. I would call this article Stage 2: Do the approved thing.

It's an important stage. But people who stay in this stage too long become intolerable technical architects who yammer away about best practices and high level company goals, produce technical documents no one reads and plan team building events no one wants to attend.

To me stage 3 involves thinking critically about tradeoffs. Applying best practices in relevant contexts and rejecting them in others is a good example.

I always end up linking this silly blog post. https://medium.com/@webseanhickey/the-evolution-of-a-softwar... It sums up the seniority growth cycle better than I can in words.

Re: Signs of an Immature Software Developer

#86

Post by minimaul »

Netcob wrote: post #82
minimaul wrote: post #74

Earlier quoted context omitted.

+1 For the juniors on my team, the next question I always ask after the answer "it's best practice" is always "why is it best practice?" It's fundamentally important to understand why something is best practice, so that you know when it is not the best course of action.

Seniors can make the same mistake - I had one literally senior colleague argue that he's been coding for decades longer than I have (I was only coding for ~15 years at the time) and that I should just do as he says, but would not tell me why, or how that applied to the situation.

Definitely. I even had the previous lead developer at $work love to say that things were best practice without really giving much justification - it's fuelled my quest for 'why?' a great deal :)

Re: Signs of an Immature Software Developer

#87

Post by prox »

bardworx wrote: post #31
chrisseaton wrote: post #10

Earlier quoted context omitted.

How do we know what the ‘best’ practices are? Presumably everyone thinks their own practices are the best, otherwise they wouldn’t be doing them. ‘Accept best practices’ just sounds like ‘do it my way because it’s the best’.

“Best Practice” are usually zoomed out, birds eye view solutions. It’s hard to argue with “you should use a version control” unless you have a very good reason not to. However, if you get into the “you should always use single quotes” argument, in my opinion, that’s too shallow to be a “best practice”.

Exactly, also the difference between telescopic vs microscopic work. Code needs to be clear is a telescopic view. Your app needs to run 200fps is more specific, microscopic. A game might need to, a text processor might not. Circumstances dictate circumnavigation.

Re: Signs of an Immature Software Developer

#88

Post by ratww »

bhntr3 wrote: post #85
goto11 wrote: post #6

I take issue with point 4 "Rejecting of Best Practices". The article states "Simply put, best practices are non negotiable.". Problem is, "best practices" is large body of rules-of-thumb which are almost always context dependent and often contradictory. Often they lead to worse code overall when applied outside of the relevant context. So I would reformulate as: Only reject a "best practice" if you understand why it…

Maturity (or seniority) is a form of growth and it has stages. I would call this article Stage 2: Do the approved thing. It's an important stage. But people who stay in this stage too long become intolerable technical architects who yammer away about best practices and high level company goals, produce technical documents no one reads and plan team building events no one wants to attend. To me stage 3 involves thinki…

"Stage 2" is very comfortable. It can give you a lot of power without the effort of doing research and acquiring experience.

Re: Signs of an Immature Software Developer

#89

Post by runawaybottle »

not_knuth wrote: post #38

While I can agree with some of the points made while gritting my teeth, the way this is written somehow puts me off. It feels as though the author has taken an authoritive, slightly condescending stance towards his readers. The message it sends is that the author is out to invalidate his readers, judge them, not take their hand and teach them. I assume the intention was otherwise, but it is not presented as such. It…

No matter who gives this observation, the presentation will always have a patronizing tone.

It’s really the discussion here on HN that’s curing it, which is fine. Someone had to get us the meat before we could cook it. There’s a lot of consensus here and good counter points that aren’t all damning (half it can be chalked up to inexperience, or effort vs value debates, eg TDD, impressionable developers, etc).

Post reply on HN