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

91–100 of 100 posts

Re: Signs of an Immature Software Developer

#91

Post by jandrewrogers »

auspex wrote: post #34
jniedrauer wrote: post #21

> Do Test Driven Development A lot of this is common sense stuff, but it might be better to replace this part with "Write tests." TDD is the kind of thing that sounds great in a blog post, but doesn't actually seem to work in the real world. At the very least, TDD is not a benchmark of a "mature software developer."

TDD does work quite well if you follow it. Why do you think it doesn’t work in practice?

TDD makes the assumption that logic is modular and that correctness can be evaluated on small subsets of code in isolation. This is not actually true in some important software domains if you are designing the code correctly. For some software, behavioral correctness can only be evaluated in the context of runtime side effects from other parts of the system. Correctness is a property of the aggregate system, not its components. In these cases, most of the testing is high-level integration testing and writing proper tests is often sufficiently sensitive to implementation detail that you write them when the code is mostly complete so that they match the implementation detail.

As an example, any data infrastructure software that uses non-trivial adapative scheduling to optimize concurrency and throughput famously has this property. It is also the primary reason things like database engines are effectively untestable until the code is nearly complete. In principle you could architect any software to be amenable to TDD, but for these cases the performance penalty implied by that architecture is so severe (literally on the order of 10x) that no one serious would design their software that way.

In these cases, the same binary can pass testing on one machine and fail on another. It is a different discipline than classic TDD, and more critical as more software systems are implicitly distributed.

Re: Signs of an Immature Software Developer

#92

Post by villasv »

ramraj07 wrote: post #53
villasv wrote: post #40

Earlier quoted context omitted.

It “does actually seem to work” at my workplace.

And so I have noticed teams and orgs which go for eternity without seeing effective examples of TDD in practice. Is there any resource which might help people like that (includes me?) something that shows TDD in real life scenarios maybe.

I wouldn't know what resource to point without having a lot more context. And even if I had, I don't feel qualified to properly give you a diagnostic.

All I can give is my anecdotal evidence. Most of our development teams apply TDD most of the time. We're working on a mature (5y) enough codebase to have a stable foundation. We do lots of integration testing and our testing is not without issues (it's slow, some of it is flaky, lots of test fixtures that are a pain to manage) but those issues do not come from TDD and are being dealt with piecemeal.

The only downside of TDD I've personally witnessed in practice is tendency to write superfluous tests. They either don't test anything useful (e.g. things already guaranteed by types) or leak implementation details. But we encourage developers to improve those tests and the engineering team is overwhelmingly positive that TDD has been a net win for productivity.

We try to deploy as much pair-programming as we can and the TDD methodology is specially improved by this. It helps dealing with loose ends from the task description or the technical kick-off and double-checking if the task acceptance criterion makes sense. If one developer of the pair has to take off halfway through, the most important bit is already agreed upon and the code review is much easier later on. Or if the pair-programming starts halfway through, the arriving developer can read the tests to catch up and help make the other tests pass.

Re: Signs of an Immature Software Developer

#93

Post by Viliam1234 »

VLM wrote: post #77

WRT the code zealot listing, there is a problem with non-idiomatic code. For example most modern languages have list comprehension and some kind of built in map-reduce on a collection built in for free, nicely debugged, etc. Once in awhile you'll run into noob code where someone writes their own long elaborate and buggy routine full of if/then and goto to slowly iterate a pointer thru an array, sometimes skipping the…

I have seen a Java code where a "senior developer" (a guy hired a few months before me, therefore considered expert by the management) reinvented an associative array. Two lists (one for the keys, one for the values), with methods to add an item and get an item. Not even encapsulated as a new type, but a separate pair of lists and pair of methods for each associative array... there were dozens of instances in the code.

On the positive side, fixing bugs in his code was often easy. First I refactored hundreds of lines of code into ten lines, then I added the missing "if".

Re: Signs of an Immature Software Developer

#94

Post by karmakaze »

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…

It does have a whiff of ego in the style. It's already odd to have a 'company' domain show 'My Blog' on the home page.

Even to call the signs 'immature' isn't helpful, as it implies that a dev is not as mature as they 'should' be. An illustrative quote is "Immaturity is something that comes with age." Junior would be a more fitting description, as that's only referring to their current progress rather than a judgement.

Re: Signs of an Immature Software Developer

#95

Post by Gibbon1 »

politelemon wrote: post #45
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’.

I think we don't know. The term best practices is now so overused that it's lost its meaning and usefulness. On a similar vein... whatever it is you're doing, it's an anti pattern.

I just remembered my first thought when I first heard someone say 'best practices'

'There is a Glittering Generality if I ever heard one'

https://en.wikipedia.org/wiki/Glittering_generality

Re: Signs of an Immature Software Developer

#96

Post by justsomeuser »

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…

I agree, in software you are often designing custom things that need to take a subset of principles from many contradictory high level best practises.

Best practises are negotiable if you can attack them with first principles. This is the basis of critical thinking, which I think is more important than best practises.

Best practises will get you fast social agreement though, whilst critical thinking will upset many people because you challenge their idea's trying to find issues early or better options.

Re: Signs of an Immature Software Developer

#97

Post by [deleted] »

tiddles wrote: post #25
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…

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…

[deleted]

Re: Signs of an Immature Software Developer

#98

Post by clusmore »

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…

I think this starts with the title, "Signs of an Immature Software Developer". This immediately puts the reader on the defensive, because nobody wants to be called or considered immature. If a junior developer were to read this and see some of their own mistakes, I think they would be unlikely to be in the right frame of mind to take the feedback onboard and try to address it. The article doesn't appear to be following its own advice, to hone your communication skills. I would suggest having a(nother) read of How to Win Friends and Influence People. A better title might be "5 Growth Areas for Junior Developers", with a corresponding flipping in phrasing of the subheadings (e.g. "Being a Tech Zealot" -> "Being Pragmatic", "Lack of Team Focus" -> "Team Focus").

Re: Signs of an Immature Software Developer

#99

Post by ta988 »

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

The comment section on HN would become much easier to read if that was applied!

Re: Signs of an Immature Software Developer

#100

Post by bluishgreen »

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…

Infact they got it backwards. It takes confidence won from experience and paid for with crisis to say screw that to "Best Practices"
Post reply on HN