Somehow missing (6), which is calling a fellow professional or coworker "immature".
Signs of an Immature Software Developer
11–20 of 100 posts
Re: Signs of an Immature Software Developer
#126. 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.
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.
Re: Signs of an Immature Software Developer
#13Sorry, 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
Re: Signs of an Immature Software Developer
#14> Focus on the business problem, not the code Staffing and code maintenance are business problems. The tech matters at various levels of concern.
Only when software is the product, when not, it doesn't really matter as long as those groceries keep being registered on the sales inventory platform, the trucks get loaded with the right amount of goods, or whatever is the actual purpose of the business.
In such cases the IT department is most likely a couple of managers for external contractors delivering projects organized per budget packages.
Re: Signs of an Immature Software Developer
#15I 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…
Either that or the author is a best practices zealot.
Re: Signs of an Immature Software Developer
#16I 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’m sure if the author would expand on that statement, they would have a similar conclusion.
It’s just easier to say “Always follow” as you should always follow best practices until you have a great reason not to.
Re: Signs of an Immature Software Developer
#17I 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 realignment means they eat up any and all bullshit they see at a developer conference or resort to appealing to authority (‘this is how Google does it’). And why wouldn’t they, they are in their eyes almost there, almost like the best.
Ultimately, this is still sincere, just leads to dumb results at times (eh, more like often). It is a form of establishing your own authority by associating yourself with authority, a coopting of something undeserved, but emotionally fulfilling. You feel like 6-7 years is enough, but it just ain’t. In it’s worst form, this is what it is and it’s pretty annoying to deal with.
/end Saturday morning psycho babble
Re: Signs of an Immature Software Developer
#18Software engineering has been solved and if you don't agree then you must be immature.
Re: Signs of an Immature Software Developer
#19> 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.
Re: Signs of an Immature Software Developer
#20Took me a second or two find the article. I thought I was on wrong page.