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

One common behavior seen in “mature” software engineers

luu.io

Post reply on HN
Print view View original

101–110 of 123 posts

Re: One common behavior seen in “mature” software engineers

#101

Post by Falkon1313 »

taeric wrote: post #24

I've grown wary of folks in senior spots that are completely oblivious to the problems they cause in the name of going beyond. All too often, today's problems stem from yesterday's solutions. This does not mean that yesterday someone made a mistake. It just means progress moves answers. If you did make a choice that feels evergreen, it is just as likely that you are oblivious to work other people are doing. To that e…

>I've grown wary of folks in senior spots that are completely oblivious to the problems they cause in the name of going beyond.

Like over-abstraction, adding layers of indirection, changing things to use generic code that has no clear relation to the problem domain (and complicates domain-related changes to business requirements), then making other parts of the system (or other systems) re-use those same generic abstractions, so that they're all coupled and/or have increased dependencies?

A good abstraction can be useful, and can even simplify things, but sometimes adding abstractions can be injecting second-system effect into an existing system. Whenever I think of doing something that could turn out like that, I try to get at least a couple of my teammates opinions on it before I even start.

Re: One common behavior seen in “mature” software engineers

#102

Post by euroderf »

clumsysmurf wrote: post #13

> They take the extra step to make sure the next person won't have to spend the same level of energy fixing the same issue, or eliminate the problem class altogether for their team. Conversely, I find it frustrating when engineers do the absolute minimum, avoid refactors, and put the next person at a disadvantage ... all while their velocity is recognized by management as good.

Doing these kinds of unnoticed forward-looking remedial things provide the doer with good conscience and inner satisfaction, but do not put the doer on a fast track to career success and riches. It's the nature of the economic beast.

And thus the current state of "civilization".

Re: One common behavior seen in “mature” software engineers

#103

Post by deafpolygon »

Ma8ee wrote: post #62
testfrequency wrote: post #35

Earlier quoted context omitted.

I saw this often. The heroes who are up late, solving a page or mitigating an outage are often the ones remembered and rewarded. Meanwhile, a dependable, resourceful, and independent IC who “picks up trash on the floor”, promotes good work habits, and is dead reliable - no praise, they are just “doing their job” Managers and leaders like drama, most staff and senior engineers gravitate to drama and love talking about…

Yes, this is my problem. I'm seen as slow, because I take my time to deliver my stuff. And I'm rarely the hero of fixing some outage or some critical bug. Because my stuff works, quietly. The heros are always busy; fixing that bug and extinguishing that fire and delivers the new feature in a day (as soon as they clean up the latest incident). What people see is that I take three days to deliver the same feature. What…

Reminds me of my time as a sysadmin managing over 100 individual linux boxes by myself. Nothing ever broke (in dramatic fashion, I mean) and new stuff were delivered on a steady schedule. I didn't spend all my time fighting fires, so the perception was that I wasn't doing anything amazing. I have to constantly point out the uptime, that every single case that needed it, we always had data recovery, but that was just considered part of my job.

Re: One common behavior seen in “mature” software engineers

#104

Post by euroderf »

agumonkey wrote: post #56

So the young soldier moved the stone, marked the area, and warned everybody about this to spare them. He was mocked and bullied by everybody. ps: don't forget about herd psychology and politics, not all peers want to see your good deeds, no matter how generous or useful they are.

There's a mindset that sees this good deed being done and says, "Sucker!".

Re: One common behavior seen in “mature” software engineers

#105

Post by euroderf »

vdqtp3 wrote: post #65
jongjong wrote: post #43

Earlier quoted context omitted.

I guess. But as a millennial who's been in the place of that young soldier a bit too many times, it's difficult to see it from the general's point of view. The message of subordination stands out more to me.

There's no message of subordination. The message is fix the problem, don't just plan to avoid it.

I see cultural differences here. An American will get grumpy and just fix the damned thing. Someone from another culture might sigh that someone else didn't do their job and shrug shoulders and amble away.

Re: One common behavior seen in “mature” software engineers

#106

Post by kazinator »

canucker2016 wrote: post #99
nonethewiser wrote: post #58

Earlier quoted context omitted.

Here is an easy example. You have a project that has both typescript and javascript. Someone makes a change in a JS file. They try to access a property of an object but there is a typo. You could fix the typo and be done. Or you could fix the typo, and convert the file to TS and make sure its typed.

Here's a real world example. On a product's multi-year death march, I look at the next bug assigned to me for the project-within-the-product I was on. Over an hour of diligent debugging revealed the problem - the C++ code meant to do X = Y; but someone had typed and committed: X == Y; The destructive value assignment became an innocuous comparison, whose result is immediately ignored. I decided to search the rest of…

GCC has a warning for statements with no effect like x == foo();

  $ echo "void f(int x) { x == g(); }" | gcc -Wall -W -x c -
  : In function ‘f’:
  :1:22: warning: implicit declaration of function ‘g’ [-Wimplicit-function-declaration]
  :1:19: warning: value computed is not used [-Wunused-value]

Re: One common behavior seen in “mature” software engineers

#107

Post by Sn0wCoder »

PaulKeeble wrote: post #5

The idea of fixing a whole class of problems is common in safety critical software. When you find the cause of a bug its not just about fixing the bug but looking for this pattern of failure everywhere and fixing that and then understanding the aspects that led to this class of bugs to begin with and eliminating those. Its just good engineering to solve the class of problems not just the bug in front of you. But I ha…

Just wanted to say feel your pain. My team was recently disbanded to other teams because our product has no issues and we were considered too slow. Fast forward just released a shiny new front end that is buggy and slow. 4 hot fixes in a month. At my review they said see getting you on a new team was all it took to speed you up. Well ya I guess no unit testing, and no documentation. At least I got the team to start using the linter. Another benefit is I have more family time and been working on a side project to ensure I don’t forget how to do things correctly lol. Always think this place is going to be different but timelines are king and those who hit them will be rewarded. Also can’t get much faster than 4 releases in a month which is all the boss sees on paper…

Re: One common behavior seen in “mature” software engineers

#108

Post by pkolaczk »

HeyLaughingBoy wrote: post #25
l33t233372 wrote: post #9

Earlier quoted context omitted.

> because we had no bugs in our software and there was no drama for the business to get what it wanted and needed I’m confused here. The business needed your software to have bugs for the drama? Surely this isn’t the whole story.

When the org that I was working for was doing TSP ( https://segoldmine.ppi-int.com/node/67631 ), our coach told me a story about another team and an engineer I knew very well. He got high praise for all the late nights and weekends he worked to get a product out the door. But on analysis of what he was working on and the bugs he had to deal with, if he had taken the TSP approach that my team was using, most of those…

Management also often doesn't track the amount of drama products created by "fast" teams cause later in production. Because the negative impact is often delayed, those problems are rarely attributed to the original authors of the code, who often move to new projects by that time. I've seen it so many times: a "hero" gets praised for writing a software component in a day and putting it into production quickly, despite a massive evidence showing that the maintenance of the previous N projects done by that person turned out to be literally a PITA and a constant source of drama later.

I'd love to see engineering bonuses / promotions work similar to how hiring bonuses work. You don't get a hiring bonus immediately when you recommend a new hire, but you get it once the new hire stays for N months. You shouldn't get a bonus/praise/promotion for just delivering software quickly. You should get it after it runs consistently and painlessly in production for N months.

Post reply on HN