Signs of an Immature Software Developer • Hacker News Board

Re: Signs of an Immature Software Developer

#31

Post by bardworx » Sat, Apr 03, 2021, 1:55 PM UTC

chrisseaton wrote: post #10

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…

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

Re: Signs of an Immature Software Developer

#32

Post by sseagull » Sat, Apr 03, 2021, 1:56 PM UTC

ckdarby wrote: post #5

Supermancho wrote: post #4

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

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.

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.

Re: Signs of an Immature Software Developer

#33

Post by tarkin2 » Sat, Apr 03, 2021, 1:57 PM UTC

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…

That's my experience.

At the start I followed design patterns religiously. I was proud that I'd use those patterns. I wrote about them. I told employers. They employers were impressed. The code was an over-engineered mess. But it ticked the best practices box.

It still happens now. But this is mainly because management and other developers are enthusiastic about various techniques that have the label "best practice".

I last left a codebase in an international firm where everything was a dependency and everything was injected and everything was orchestrated. Everyone was enthusiastic that they finally had a codebase with dependency injection everywhere. I hope to never see that codebase again.

Re: Signs of an Immature Software Developer

#34

Post by auspex » Sat, Apr 03, 2021, 1:59 PM UTC

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?

Re: Signs of an Immature Software Developer

#35

Post by mrloba » Sat, Apr 03, 2021, 1:59 PM UTC

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.

Re: Signs of an Immature Software Developer

#36

Post by riffraff » Sat, Apr 03, 2021, 2:00 PM UTC

addicted wrote: post #7

hashkb wrote: post #3

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.

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.

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.

Re: Signs of an Immature Software Developer

#37

Post by robjan » Sat, Apr 03, 2021, 2:00 PM UTC

addicted wrote: post #7

hashkb wrote: post #3

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.

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.

Senior developers learn that everything is negotiable

Re: Signs of an Immature Software Developer

#38

Post by not_knuth » Sat, Apr 03, 2021, 2:00 PM UTC

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.

Re: Signs of an Immature Software Developer

#39

Post by redpenguin101 » Sat, Apr 03, 2021, 2:04 PM UTC

lxe wrote: post #29

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.

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

Re: Signs of an Immature Software Developer

#40

Post by villasv » Sat, Apr 03, 2021, 2:04 PM UTC

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

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