5 ms·

Signs of an Immature Software Developer

73 points by kiyanwang 6y ago

sseagull 6y ago
> 5. Happy Path Focused Preach it! I am dealing with this now, having taken over a project from someone who thought this way. Yes it works, but is full of bad error handling, cryptic exceptions, race conditions (particularly TOCTOU bugs), non-atomic database updates, and more. "But it works" they say, which is true. But a simple SQL query shows duplicate or missing data where there shouldn't be and other violations of basic assumptions. Looking at code and knowing what could possibly go wrong is an extremely useful skill. Unfortunately it usually takes running head first into those issues to actually learn and comprehend those lessons (which I have done more than my fair share of :))
- smoe 6y ago
  I have also seen the other extreme. Where people are overly paranoid about the app throwing any exception and try to capture everything that could possibly go wrong until the heat death of the universe. Handling every error somehow, often without understanding what is supposed to happen in this case. So you end up with things being in weird states and secondary effects for what would have just thrown a fairly easy to troubleshoot exception otherwise.
hashkb 6y ago
6. Posting click bait titles to your programming blog. Edit: here's a real critique. > Best practices are non-negotiable Have you ever argued about which practice was best? I have, many times. They are endlessly negotiable, and there is no canonical list of best practices.
- addicted 6y ago
  Non negotiable best practices does not mean it’s not arguable which practices are best. What it means is whatever you or your company decides are best practices as well as agreed upon industry best practices must be followed every time.
  - ratww 6y ago
    > practices must be followed every time This is only good advice if you're solving very simple, very trivial problems, or if you don't have enough experience. (That, or if you redefine best practices to tautologies like "always test" or "always write good code"). For anything more complicated than the most trivial of software, it's important to deeply understand your best practices and if they make sense to each situation or not. Software is hard. There are no silver bullets.
  - riffraff 6y ago
    but why should they? For example, you may have a rule that you need CI to pass to merge a branch to your trunk. But maybe CI is slow and flaky, and a business test fails on a PR where you've only changed the README. Sure, you can say "well, the rule is to only merge with green CI" and restart the failed job, but you can also think "well, I can merge this". Maybe it's ok, maybe not, but I think you should trust your fellow developers with doing the right thing rather than berate them "you didn't follow the rules!" Only a sith deals in absolutes.
  - robjan 6y ago
    Senior developers learn that everything is negotiable
- tonyarkles 6y ago
  They jumped out at me too. In software specifically, I’ve seen a lot of Best Practices come and go over the years and they’ve often contradicted the previous ones. Plus there are situations where I can, with good conscience, say “best practices say we should do X here, but because of reasons A, B, and C, I think we should do it this way instead.” The real trick is a) getting your team to agree on what practices to follow, and b) agreeing that if you’re going to deviate from them that there’s an expectation that you’ll need to justify that. “I did it this way because it’s the first thing I thought of” vs “I reasoned my way through this and this is why we should do it this way” are very different situations, even if they result in the same code.
Supermancho 6y ago
> Focus on the business problem, not the code Staffing and code maintenance are business problems. The tech matters at various levels of concern.
- ckdarby 6y ago
  The code can have the least amount of technical debt, be written in the most simplistic way and be abstracted enough to allow the business to evolve but if the business runs out of money nobody cares about the rest because it won't matter. Staffing and code maintenance are a business problem but I see software developers early in their journey put too much weight on these compared to bottom line value to the company.
  - genezeta 6y ago
    So maybe the right balance then should be acknowledging the correct value of code. Don't focus on code, but also don't neglect it. Don't put it over bottom line value, but also don't ignore it. I have seen inexperienced developers and managers -and also developers with a lot of wrong experience- sink enormous amounts of time/money into maintaining extremely bad code without even noticing where the cost came from.
  - sseagull 6y ago
    There are always extremes, of course. But I find that a large share of technical debt could have been solved from the beginning with a little bit of foresight and planning. Of course stakeholders often have a way of upending your beautiful design, but one of the core tenets of agile is to design your code to be adaptable. Done upfront, the cost is usually minimal but can completely save you when your client asks for the dreaded "small change". YMMV of course. It's a big world out there.
  - Supermancho 6y ago
    > if the business runs out of money nobody cares about the rest because it won't matter. "Business problems" aren't constrained here to "startups". Most business concerns are things that already exist in successful companies, because they are in business.
goto11 6y ago
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 was there in the first place. Maybe I'm just being immature, though! Otherwise some good points in the article. I'd say a good sign of maturity is that you understand you job isn't to write code, your job is solving problems for the business.
- chrisseaton 6y ago
  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’.
  - bardworx 6y ago
    “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”.
    - prox 6y ago
      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.
  - politelemon 6y ago
    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.
deleted 6y ago
[deleted]
ratww 6y ago
> 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 and benefits. This means discussing and yes, negotiating what are considered "best practices", and sometimes rejecting them if they're getting in the way of having a good product.
- faeyanpiraat 6y ago
  Even if you are aware of the why, you need something (wisdom, extensive experience, etc..) to be sure when to enter into confrontations whether or not a particular best practice should or should not be used.
- why_Mr_Anderson 6y ago
  I'd say it's more likely sign of Dunning-Krueger. But I fully agree with the rest of your comment, the more decades I spend programming, the more I realize that the answer to pretty much any question related to SW development should start with "It depends. ..."
  - ratww 6y ago
    > I'd say it's more likely sign of Dunning-Krueger. Yep. I was thinking of the same thing when writing other comments. It's very comfortable to "believe" one has the perfect answer to an entire class of problems, but it's never the reality.
- rantwasp 6y ago
  i think there is more nuance to this. If you know what the best practices are in general, you understand them and have a really good reason to reject one or two of them that’s one thing. If you reject everything because “you know batter” that’s a totally different story.
- kar5pt 6y ago
kchoudhu 6y ago
Somehow missing (6), which is calling a fellow professional or coworker "immature".
- tarkin2 6y ago
  Publicly reprimanding past, present and future colleagues in order to boost your own standing by setting goal posts may be a bit of red flag, for my money at least. Writing about specific issues, with examples, to teach a general-rule, ideally in a humble way, rather than setting goal-posts, would be more productive.
Blsht20210403 6y ago
Sorry, but this is a bunch of bullshit. Here is the market truth: 1) know very latest tech 2) know algos very well 3) have hot brands as past work places
- dsugarman 6y ago
  I think your list is probably the right list for getting a high paying job but pretty wrong for being an effective developer. I think that's what you were saying in a cynical way anyway.
- atleta 6y ago
  Very elegant. So you created an anonymous account to post an ignorant comment, without any argument, in a rude style.
postalrat 6y ago
Software engineering has been solved and if you don't agree then you must be immature.
electric_muse 6y ago
> When changing the world or providing a service, languages/tools take the back seat. The founders of any startup don’t care what language you use to complete the goal. As a founder, I have found that the tech stack choice does matter beyond just getting the problems solved. When hiring, engineers have judged joining my company based on our tech stack. Not just about familiarity, some have outright said that it’s because they only want to learn the most popular and transferable skills. When discussing strategic acquisitions, it also matters. Interested buyers (ie for an acquisition) have asked about our tools and languages. We are more valuable if our languages and tools are compatible / common enough to fit into their organization.
anthropodie 6y ago
Took me a second or two find the article. I thought I was on wrong page.
jniedrauer 6y ago
> 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."
- auspex 6y ago
  TDD does work quite well if you follow it. Why do you think it doesn’t work in practice?
  - faeyanpiraat 6y ago
    I’m not OP and do not want to state whether TDD works or not, but in my experience it would increase development work significantly on apps which have complicated state machines as their business logic. It would probably end up being less work overall, when we factor in all the bug fixing work, that would happen after such an app would’ve been released without TDD.
  - jniedrauer 6y ago
    There may be a domain where it makes a lot of sense, but I've rarely encountered it. Writing and maintaining test code takes just as much time as any other code. You often encounter problems during the actual implementation part that challenge your preconceptions. So if you write the tests first, then you'll end up rewriting them many times. TDD also encourages you to write junk tests that provide no safety, which will then need to be maintained and fixed at every refactor. But the biggest problem is that others on the teams simply won't do it, and neither will you when a deadline looms near. TDD aspirations don't last very long in production. The one place where I think it works well is implementing a well defined protocol. If you have exact definitions for inputs and outputs, then writing the tests first can make things a lot easier. But it's rare when you have such a clean problem to solve.
  - jandrewrogers 6y ago
    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.
why_Mr_Anderson 6y ago
It would have more weight behind if you wrote about your background, e.g. "20yrs of SW dev",etc. As it is now, your post looks like chapter list in a generic "Learn SW dev in 24 hours" book.
riffraff 6y ago
I think "having rigid rules is a sign of immaturity", which also applies when you're establishing rules about immaturity. I may be wrong tho.
lxe 6y ago
Lots of critical nuance is missing, making it sound like it’s written by a “happy-path” eng manager. If your “mature engineers” are business- and team-focused (read: doing what they are told), disregard innovations in tech and evolution (and evangelism) of best practices, you’re gonna have a boring team that will eventually get disrupted either from outside or inside of your org.
- redpenguin101 6y ago
  > business- and team-focused (read: doing what they are told) "Doing what they are told" strikes me as the antithesis of being business and team focused - particularly the former. A non-business focused engineer is mindlessly implementing the solutions the business asks for, without taking the time to understand the problem, motivation or mental-model of the business. A non-team focused engineer is narrowly implementing the tasks that end up assigned to them, with no interest in what the rest of the team is doing, and not engaging with the wider team to challenge and contribute to what they are doing.
- why_Mr_Anderson 6y ago
  Business-oriented means "we do realize that the money don't magically materialize out of thin air and that anything that keeps customers happy/helps attract more is significantly more important than any code purism nonsense."
mrloba 6y ago
To me the biggest one is not understanding and solving the actual problem that needs to be solved. Instead people will solve problems that the business doesn't have, or technical issues that doesn't exist. Or just some mildly related more fun problem instead.
not_knuth 6y ago
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 reeks of a junior with strong opinions rather than an old software jedi that intends to teach us the mastery of the art.
- runawaybottle 6y ago
  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).
- karmakaze 6y ago
  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.
- clusmore 6y ago
  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").
AzzieElbab 6y ago
So tired of these. Are founders really this dumb today that they are incapable of grasping trade offs when it comes to both people and platforms?
one2three4 6y ago
<cynic> Signs of an Immature preacher. Define a bunch of rules that sound good. Ignore contradictions between them. Write blog posts and books. Live off the proceedings of the cult you built. </cynic> TDD is PITA and I do not know any one soul that actually follows it. But it does sound good. Best Practices are a dozen a dime and if anything they can serve as to identify which kind of books the team lead once read. I could go on but I'm seriously bored by this type of posts/attitude. I only commend because nowdays they seem to come disguised as "pragmatic". There are some valid points in there but there are zealot red-flags as well. Funny enough 'no zealots' is one of the points.
toomanybeersies 6y ago
> Rejecting of Best Practices On the contrary, I think that a sign of a mature software developer is understanding why particular "best practices" exist, and when it's appropriate to reject them.
weeboid 6y ago
Wait, can we still rip on PHP though
deleted 6y ago
[deleted]
AtNightWeCode 6y ago
Best practices are for beginners. Experts don't think about rules.
debrice 6y ago
“Best practices are non-negotiable” In my experience (over 20 years) rules are meant to be broken. You can’t have a set of meaningful rules that can’t be misfits in some cases. “Write unit-tests!” - on a shell script? - for my playbook? - on that static html-css? - on my docker config?... You’ll learn that best practices are great guidelines when you begin. Once you’re seasoned you’ll know what’s right... that’s what make you senior. You don’t ignore them, you use them wisely.
ectopod 6y ago
Requiring javascript to read a simple article doesn't seem very pragmatic.
VLM 6y ago
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 first or last element of the array, etc. But if all an immature dev knows is "if then and goto" and not that fancy list comprehension stuff, you can get some crazy looking code that can be optimized, sometimes, down to one idiomatic line of code. There are of course other examples of non-idiomatic code. Now is DRY don't repeat yourself idiomatic or a best practice or both or ?
- Viliam1234 6y ago
  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".
driveintheatre 6y ago
The linked website is awful, has like two blog posts ever, no author byline, nothing. But the title baits another eng. dick measuring contest, let's go HNers!

73 points by kiyanwang 6y ago

> 5. Happy Path Focused Preach it! I am dealing with this now, having taken over a project from someone who thought this way. Yes it works, but is full of bad error handling, cryptic exceptions, race conditions (particularly TOCTOU bugs), non-atomic database updates, and more. "But it works" they say, which is true. But a simple SQL query shows duplicate or missing data where there shouldn't be and other violations of basic assumptions. Looking at code and knowing what could possibly go wrong is an extremely useful skill. Unfortunately it usually takes running head first into those issues to actually learn and comprehend those lessons (which I have done more than my fair share of :))

smoe 6y ago
I have also seen the other extreme. Where people are overly paranoid about the app throwing any exception and try to capture everything that could possibly go wrong until the heat death of the universe. Handling every error somehow, often without understanding what is supposed to happen in this case. So you end up with things being in weird states and secondary effects for what would have just thrown a fairly easy to troubleshoot exception otherwise.

hashkb 6y ago

6. Posting click bait titles to your programming blog. Edit: here's a real critique. > Best practices are non-negotiable Have you ever argued about which practice was best? I have, many times. They are endlessly negotiable, and there is no canonical list of best practices.

addicted 6y ago
Non negotiable best practices does not mean it’s not arguable which practices are best. What it means is whatever you or your company decides are best practices as well as agreed upon industry best practices must be followed every time.
- ratww 6y ago
  > practices must be followed every time This is only good advice if you're solving very simple, very trivial problems, or if you don't have enough experience. (That, or if you redefine best practices to tautologies like "always test" or "always write good code"). For anything more complicated than the most trivial of software, it's important to deeply understand your best practices and if they make sense to each situation or not. Software is hard. There are no silver bullets.
- riffraff 6y ago
  but why should they? For example, you may have a rule that you need CI to pass to merge a branch to your trunk. But maybe CI is slow and flaky, and a business test fails on a PR where you've only changed the README. Sure, you can say "well, the rule is to only merge with green CI" and restart the failed job, but you can also think "well, I can merge this". Maybe it's ok, maybe not, but I think you should trust your fellow developers with doing the right thing rather than berate them "you didn't follow the rules!" Only a sith deals in absolutes.
- robjan 6y ago
  Senior developers learn that everything is negotiable
tonyarkles 6y ago
They jumped out at me too. In software specifically, I’ve seen a lot of Best Practices come and go over the years and they’ve often contradicted the previous ones. Plus there are situations where I can, with good conscience, say “best practices say we should do X here, but because of reasons A, B, and C, I think we should do it this way instead.” The real trick is a) getting your team to agree on what practices to follow, and b) agreeing that if you’re going to deviate from them that there’s an expectation that you’ll need to justify that. “I did it this way because it’s the first thing I thought of” vs “I reasoned my way through this and this is why we should do it this way” are very different situations, even if they result in the same code.

Supermancho 6y ago

> Focus on the business problem, not the code Staffing and code maintenance are business problems. The tech matters at various levels of concern.

ckdarby 6y ago
The code can have the least amount of technical debt, be written in the most simplistic way and be abstracted enough to allow the business to evolve but if the business runs out of money nobody cares about the rest because it won't matter. Staffing and code maintenance are a business problem but I see software developers early in their journey put too much weight on these compared to bottom line value to the company.
- genezeta 6y ago
  So maybe the right balance then should be acknowledging the correct value of code. Don't focus on code, but also don't neglect it. Don't put it over bottom line value, but also don't ignore it. I have seen inexperienced developers and managers -and also developers with a lot of wrong experience- sink enormous amounts of time/money into maintaining extremely bad code without even noticing where the cost came from.
- sseagull 6y ago
  There are always extremes, of course. But I find that a large share of technical debt could have been solved from the beginning with a little bit of foresight and planning. Of course stakeholders often have a way of upending your beautiful design, but one of the core tenets of agile is to design your code to be adaptable. Done upfront, the cost is usually minimal but can completely save you when your client asks for the dreaded "small change". YMMV of course. It's a big world out there.
- Supermancho 6y ago
  > if the business runs out of money nobody cares about the rest because it won't matter. "Business problems" aren't constrained here to "startups". Most business concerns are things that already exist in successful companies, because they are in business.

goto11 6y ago

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 was there in the first place. Maybe I'm just being immature, though! Otherwise some good points in the article. I'd say a good sign of maturity is that you understand you job isn't to write code, your job is solving problems for the business.

chrisseaton 6y ago
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’.
- bardworx 6y ago
  “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”.
  - prox 6y ago
    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.
- politelemon 6y ago
  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.

deleted 6y ago

[deleted]

ratww 6y ago

> 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 and benefits. This means discussing and yes, negotiating what are considered "best practices", and sometimes rejecting them if they're getting in the way of having a good product.

faeyanpiraat 6y ago
Even if you are aware of the why, you need something (wisdom, extensive experience, etc..) to be sure when to enter into confrontations whether or not a particular best practice should or should not be used.
why_Mr_Anderson 6y ago
I'd say it's more likely sign of Dunning-Krueger. But I fully agree with the rest of your comment, the more decades I spend programming, the more I realize that the answer to pretty much any question related to SW development should start with "It depends. ..."
- ratww 6y ago
  > I'd say it's more likely sign of Dunning-Krueger. Yep. I was thinking of the same thing when writing other comments. It's very comfortable to "believe" one has the perfect answer to an entire class of problems, but it's never the reality.
rantwasp 6y ago
i think there is more nuance to this. If you know what the best practices are in general, you understand them and have a really good reason to reject one or two of them that’s one thing. If you reject everything because “you know batter” that’s a totally different story.
kar5pt 6y ago

kchoudhu 6y ago

Somehow missing (6), which is calling a fellow professional or coworker "immature".

tarkin2 6y ago
Publicly reprimanding past, present and future colleagues in order to boost your own standing by setting goal posts may be a bit of red flag, for my money at least. Writing about specific issues, with examples, to teach a general-rule, ideally in a humble way, rather than setting goal-posts, would be more productive.

Blsht20210403 6y ago

Sorry, but this is a bunch of bullshit. Here is the market truth: 1) know very latest tech 2) know algos very well 3) have hot brands as past work places

dsugarman 6y ago
I think your list is probably the right list for getting a high paying job but pretty wrong for being an effective developer. I think that's what you were saying in a cynical way anyway.
atleta 6y ago
Very elegant. So you created an anonymous account to post an ignorant comment, without any argument, in a rude style.

postalrat 6y ago

Software engineering has been solved and if you don't agree then you must be immature.

electric_muse 6y ago

> When changing the world or providing a service, languages/tools take the back seat. The founders of any startup don’t care what language you use to complete the goal. As a founder, I have found that the tech stack choice does matter beyond just getting the problems solved. When hiring, engineers have judged joining my company based on our tech stack. Not just about familiarity, some have outright said that it’s because they only want to learn the most popular and transferable skills. When discussing strategic acquisitions, it also matters. Interested buyers (ie for an acquisition) have asked about our tools and languages. We are more valuable if our languages and tools are compatible / common enough to fit into their organization.

anthropodie 6y ago

Took me a second or two find the article. I thought I was on wrong page.

jniedrauer 6y ago

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

auspex 6y ago
TDD does work quite well if you follow it. Why do you think it doesn’t work in practice?
- faeyanpiraat 6y ago
  I’m not OP and do not want to state whether TDD works or not, but in my experience it would increase development work significantly on apps which have complicated state machines as their business logic. It would probably end up being less work overall, when we factor in all the bug fixing work, that would happen after such an app would’ve been released without TDD.
- jniedrauer 6y ago
  There may be a domain where it makes a lot of sense, but I've rarely encountered it. Writing and maintaining test code takes just as much time as any other code. You often encounter problems during the actual implementation part that challenge your preconceptions. So if you write the tests first, then you'll end up rewriting them many times. TDD also encourages you to write junk tests that provide no safety, which will then need to be maintained and fixed at every refactor. But the biggest problem is that others on the teams simply won't do it, and neither will you when a deadline looms near. TDD aspirations don't last very long in production. The one place where I think it works well is implementing a well defined protocol. If you have exact definitions for inputs and outputs, then writing the tests first can make things a lot easier. But it's rare when you have such a clean problem to solve.
- jandrewrogers 6y ago
  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.

why_Mr_Anderson 6y ago

It would have more weight behind if you wrote about your background, e.g. "20yrs of SW dev",etc. As it is now, your post looks like chapter list in a generic "Learn SW dev in 24 hours" book.

riffraff 6y ago

I think "having rigid rules is a sign of immaturity", which also applies when you're establishing rules about immaturity. I may be wrong tho.

lxe 6y ago

Lots of critical nuance is missing, making it sound like it’s written by a “happy-path” eng manager. If your “mature engineers” are business- and team-focused (read: doing what they are told), disregard innovations in tech and evolution (and evangelism) of best practices, you’re gonna have a boring team that will eventually get disrupted either from outside or inside of your org.

redpenguin101 6y ago
> business- and team-focused (read: doing what they are told) "Doing what they are told" strikes me as the antithesis of being business and team focused - particularly the former. A non-business focused engineer is mindlessly implementing the solutions the business asks for, without taking the time to understand the problem, motivation or mental-model of the business. A non-team focused engineer is narrowly implementing the tasks that end up assigned to them, with no interest in what the rest of the team is doing, and not engaging with the wider team to challenge and contribute to what they are doing.
why_Mr_Anderson 6y ago
Business-oriented means "we do realize that the money don't magically materialize out of thin air and that anything that keeps customers happy/helps attract more is significantly more important than any code purism nonsense."

mrloba 6y ago

To me the biggest one is not understanding and solving the actual problem that needs to be solved. Instead people will solve problems that the business doesn't have, or technical issues that doesn't exist. Or just some mildly related more fun problem instead.

not_knuth 6y ago

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 reeks of a junior with strong opinions rather than an old software jedi that intends to teach us the mastery of the art.

runawaybottle 6y ago
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).
karmakaze 6y ago
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.
clusmore 6y ago
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").

AzzieElbab 6y ago

So tired of these. Are founders really this dumb today that they are incapable of grasping trade offs when it comes to both people and platforms?

one2three4 6y ago

<cynic> Signs of an Immature preacher. Define a bunch of rules that sound good. Ignore contradictions between them. Write blog posts and books. Live off the proceedings of the cult you built. </cynic> TDD is PITA and I do not know any one soul that actually follows it. But it does sound good. Best Practices are a dozen a dime and if anything they can serve as to identify which kind of books the team lead once read. I could go on but I'm seriously bored by this type of posts/attitude. I only commend because nowdays they seem to come disguised as "pragmatic". There are some valid points in there but there are zealot red-flags as well. Funny enough 'no zealots' is one of the points.

toomanybeersies 6y ago

> Rejecting of Best Practices On the contrary, I think that a sign of a mature software developer is understanding why particular "best practices" exist, and when it's appropriate to reject them.

weeboid 6y ago

Wait, can we still rip on PHP though

deleted 6y ago

[deleted]

AtNightWeCode 6y ago

Best practices are for beginners. Experts don't think about rules.

debrice 6y ago

“Best practices are non-negotiable” In my experience (over 20 years) rules are meant to be broken. You can’t have a set of meaningful rules that can’t be misfits in some cases. “Write unit-tests!” - on a shell script? - for my playbook? - on that static html-css? - on my docker config?... You’ll learn that best practices are great guidelines when you begin. Once you’re seasoned you’ll know what’s right... that’s what make you senior. You don’t ignore them, you use them wisely.

ectopod 6y ago

Requiring javascript to read a simple article doesn't seem very pragmatic.

VLM 6y ago

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 first or last element of the array, etc. But if all an immature dev knows is "if then and goto" and not that fancy list comprehension stuff, you can get some crazy looking code that can be optimized, sometimes, down to one idiomatic line of code. There are of course other examples of non-idiomatic code. Now is DRY don't repeat yourself idiomatic or a best practice or both or ?

Viliam1234 6y ago
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".

driveintheatre 6y ago

The linked website is awful, has like two blog posts ever, no author byline, nothing. But the title baits another eng. dick measuring contest, let's go HNers!