[deleted]
One common behavior seen in “mature” software engineers
91–100 of 123 posts
Re: One common behavior seen in “mature” software engineers
#92This is great. I have a person at my company who doesn't even "learn the stone" for his own stuff. This person isn't even a baseline engineer - he's a negative for the whole team. And the management who doesn't recognize this is dragging us down as well.
I feel personally attacked
Re: One common behavior seen in “mature” software engineers
#93I was fired from a small ERP company that will remain nameless for fixing the broken math that caused an entire class of bugs instead of just the one bug as reported. It was a snapshot of an older version of the code base, so by giving known issues with known "correct" solutions to newer hires they could get them familiar with the code base quicker.
It was an interesting idea, but egos in the room weren't ready for the possibility that the "official" answers weren't actually correct.
I was very new there and my manager didn't understand the algebra when I showed them, and they were very uncomfortable when I showed how the general case manifested in production. I was sacked a day or two later.
It was obviously for the best, but still pretty funny that there are some places where this sort of "maturity" is frowned upon.
Re: One common behavior seen in “mature” software engineers
#94"promotion is more about consistent level N+1 behavior, while one could get a high performance rating by solving many level N problems." Not all companies are like this, and I find it common that new employees are not sufficiently taught what their company is like : A) you have been performing well as N,promotion means "we feel / hope you're ready to work as N+1 in the future " B) you've done great as N and have repe…
Has anyone been stuck in a position where you seemingly cannot land a promotion because you've had to keep taking on more responsibilities, to the point where you're beyond qualified for the next level, but you're not yet able to excel past it to the next level beyond that?
- Must achieve the highest performance rating for current responsibilities to qualify for promotion.
- But current responsibilities are actually level N+1½.
- Sometimes struggle with the responsibilities from level N+2.
- Never get promoted due to inconsistent N+2 performance.
Re: One common behavior seen in “mature” software engineers
#95Earlier quoted context omitted.
I like to rate engineers across various categories, but really I found that there were two general classes of great engineers: fast and slow. For marketing tests, etc., the whole team would be fast engineers. For payments, the whole team would be slow. Everything else I would try to have tension -- a mix of the two so they learn and appreciate each other. This is condensing a multidimensional vector into just a line,…
May I propose terminology that has less negative connotations associated with them? How about "quick" vs "deliberate"?
Focus-work that is broad and shallow versus narrow and deep.
Re: One common behavior seen in “mature” software engineers
#96"promotion is more about consistent level N+1 behavior, while one could get a high performance rating by solving many level N problems." Not all companies are like this, and I find it common that new employees are not sufficiently taught what their company is like : A) you have been performing well as N,promotion means "we feel / hope you're ready to work as N+1 in the future " B) you've done great as N and have repe…
I've seen B cause issues too. The duties of level N and N+1 are often a little different. If they're different enough, then it can be difficult to demonstrate N+1 while also doing N work. You're option is to work two jobs at once or, as I more commonly see, do the bare minimum of N work and focusing on N+1 work. This can look like the teammate who's focusing on division-wide initiatives at the expense of implementing…
Yep...we had a whole slew of people acting like N+1s on my team a couple years ago. Everyone trying to "lead" everyone else. Load of horseshit. Just get the work done. Meanwhile I feel like I'm penalized for not attempting to micromanage everyone else. My scores are great for N but I guess I'll never get N+1.
Re: One common behavior seen in “mature” software engineers
#97Something I am thinking of similar to this. Firefighter vs Gardener.
The firefighter focuses on the high stakes issue at hand and make sure it is solved in time and without much damage. The Gartner ensues the fire doesn't happen in the first place by making sure he is cleaning up the dried leaves in the first place.
But in a company environment, the firefighters are more valued are praised because that's something you can see and quantify. where as the regular cleanup/refactoring and fine-tuning the api is invisible and boring. Just a thought.
Re: One common behavior seen in “mature” software engineers
#98The 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…
I like to rate engineers across various categories, but really I found that there were two general classes of great engineers: fast and slow. For marketing tests, etc., the whole team would be fast engineers. For payments, the whole team would be slow. Everything else I would try to have tension -- a mix of the two so they learn and appreciate each other. This is condensing a multidimensional vector into just a line,…
This is an interesting observation. I like to think myself as a slow programmer. Do you think discussing this in an interview before you actually got the job in order to evaluate if you are fit to the role joining is a good idea ?
Re: One common behavior seen in “mature” software engineers
#99I'll take forced parables that don't make any sense in the metaphorical context in which they're framed for $500.
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;
X == Y;
I decided to search the rest of the tens-of-KLOCs project for similar assignment-turned-comparison statements.
That's mindless and tedious work perfectly designed for a computer.
Several minutes later, after weeding through the false positives, I created bug entries for any offenders.
Did I stop there? No.
I connected to the source server for the entire product and kicked off the same search.
When the search finished, I separated the buggy wheat from the chaff and created bug entries accordingly.
This happened on the weekend.
When the product triage team met the following weekday morning, they saw all the bugs entered across the several projects in the product due to the same root cause - double equals instead of a single equals sign.
Management decided to take the next step. They bought a site license for a static source code analyzer. We integrated the analyzer into our project build process and ran the analyzer on each build and triaging accordingly.
Highest compliment I got for creating all this "extra work": "F*ck you!" said with a smile.
Did I stop there? No.
I kept my eyes and ears on the lookout for more possible typos. I would read commit emails and resolutions to bugs to see if the cause/fix would fit the model of "easily-found-via-grep".
I expanded my batch file to cover new cases and created new bugs when the batch file found them.
Did I stop there? No.
Eventually I hit the wall of diminishing returns for source code analysis via regular-expression searching.
I looked for a tool that could go to the next level.
At that time, the one scripting language available in our project's build tools was perl.
Off to the bookstore and I bought O'Reilly's Pink Camel Perl book.
A few hours later, I had a rudimentary source code analyzer that looked at lines of source code for typos.
I added more cases as appropriate.
But C/C++ source code isn't rigidly formatted and programmers wouldn't play nice and limit their code to one code statement per source code line. Preprocessor macros also confused the line-at-a-time script analysis.
So I bit the bullet and expanded the perl script to "parse" C/C++ code.
I added checks to make sure memory allocations were checked for failure (no exception-handling for memory failure in our codebase).
Did I stop there? No.
I publicized the script within the company, answered questions, listened to suggestions, and offered help to other product groups in the company.
A couple of other product groups integrated the script into their build process. Obviously it'd be better if each programmer would run the script before they committed modified code.
Did I stop there? No.
I had worked on the company's new signature product before the current project's death march had started. I still had access to that signature product's source code. So I would run my perl script against the product's source code. That product is huge. A source code scan over the network (my work machine didn't have enough disk space to enlist in every project in the product) would take all night. I had access to the bug database but I didn't know which source code directory mapped to which project in that product.
So I did the next, most annoying thing - I sent a cleansed list of defects to all the developers in the product.
Did I stop there? No.
The company had bought a static source code analyzer product and proceeded to integrate it into most of the company's products' development process. They created a stripped down version of the source code analyzer suitable for developer use before committing code. My perl script was obsolete now.
But that didn't mean others couldn't benefit from it even though the company didn't need it anymore.
I noticed a "call for papers" notice for an open source conference.
I emailed the company's legal department and requested to open source my perl script. Their reply: "Permission granted."
I wrote my proposal, sent it into the conference organizers, who accepted the proposal, wrote a talk, and presented at the open source conference.
Did I stop there? No.
Talk is nice. Code is better. I published/uploaded the script on CPAN (the Comprehensive Perl Archive Network - https://www.cpan.org ).
Did I stop there? No.
Around the time Coverity started scanning open source projects, I had downloaded the source code to several prominent open source projects and scanned their code and sent emails with possible bugs where appropriate.
Re: One common behavior seen in “mature” software engineers
#100Really mature engineers will spend 3 months running a psyop campaign with upper management about the value of removing the stone, 3 months devising a new stoneless architecture, 15 months letting a team of underlings implement it, and a lifetime of failing upwards because they “led large scale projects.”
I like how Sarah Mei says, "Inline everything". You don't get to go on a refactoring crusade. You do it on a daily basis when you are working on the actual production issues. Easy to say but based on my experience, it is the only way to move things in the right direction and keep them that way.