Advice for a senior level developer who makes lots of mistakes

[allenbina]

I find myself technically smart, able to understand concepts and well suited for early stage development where I can follow the reasoning behind choices that are made. When I join legacy or in process projects, I find myself questioning why choices are made. Like most of you (I guess), a lot of the people I work with don't document anything, or have limited documentation from the origin of the project, and middle / upper management isn't really technical. I can follow high level flows, but I make lots of mistakes on projects with lots of moving parts. I try not to get into the mindset that the more senior people on the project are withholding information from me, but that leads me to believe that I'm not where I should be technically.

I'm starting to second guess myself a lot more, more so on older projects that I'm throw into. I'm reaching out to older teammates and asking them about my past performance and how my current projects are, and they all say I was ok, and that these projects are also the norm.

Is this usually the case? Is there a direction I should go to avoid making the same mistakes? Do you sometimes spend 2 days troubleshooting an error that you caused yourself?

[PaulHoule]

I think my brain runs at twice the cycle rate as other people's brains but the cycles are not so good so I make mistakes.

My reaction time is about 20-30% faster than my teenage son. I beat him at chess consistently even though I inevitably make one or two boneheaded mistake(s) early on but I have a good understanding how to open up and control the space I keep the pressure on relentlessly.

People have always told me not to sweat it about the mistakes that I make and that the fear of the mistakes is just going to cause more mistakes and maybe they are right.

In software I know I do exceptionally well at figuring out things like "where do I pull down data in this React application so that it can flow to all the places it needs to go" and it drives me up the wall that most people go about that kind of thing randomly and wonder why the layout is jumping up and down all the time but don't seem concerned that the render() method gets called 15 times when it only ought to get called once. Despite that, my boss catches an occasional howler of mine during a code review but that's why he does a code review.

I am in the process of rewriting my own internal "software" for interacting with people and I wouldn't know how to explain it or what I am doing except that I read a biography of Benjamin Disraeli and learn from it or watch an episode of Quantum Leap and see it as "performing arts about the performing arts" as opposed to science fiction.

[tacostakohashi]

If you're joining a big/complicated/legacy project, and want to make changes (or even get anything done), Chesterton's Fence applies.

https://fs.blog/2020/03/chestertons-fence/

There will be many things that don't make sense or look wrong initially. Its possible that they *are* wrong, and you can improve on them. The key to productivity is being able to demonstrate that your prospective changes don't break anything, and do in fact improve things.

I doubt people are "withholding information" from you, probably the people who made the decisions left, or are busy with other things now (management). It's your job to gather the information you need with what you have. It may be the case that you need to invest heavily in testing, logging, instrumentation and debugging skills on the current system to understand how and why it works as it is, and whether your changes make things better or worse.

[100011_100001]

In my experience I always give people the benefit of the doubt because I don't know what the constraints were. Multiple instances of being on the other end has given me that realization.

"Hey this looks weird"...That's because I wrote the code at 4am after production being down for 12 hours. It was meant to be a quick fix, but no one wanted to touch the code and I was sent to another project for 6 months. So yup, my stupid hard coded code is still there, and yes it breaks on leap years on February 28th...I put it in the story I wrote.

For some reason my worst code ends up being used the longest. That solution I wrote code for about 14 hours straight to save about 100 hours of wasted dev time per week. I put a note with a date "yell at me if you see this in a month", because I meant to improve it...but re-priorities took me away. Three years later I am fixing it, most of the code is trash, bad decisions made, some horrible configuration assumptions. Part of it was inexperience. Now I know any code I write might remain in the code forever...

[austincheney]

So…

Many developers never get past a composition first mindset. That is beginner shit. It’s putting legos together without the instruction manual only to stress about how the pieces click together instead what the final state is. You end up with lots of decoration and shit everywhere. In the military we call this not seeing the forest for the trees.

As a senior myself in the corporate world who enjoys writing open source software there is a world of difference between people build products and people that just write code at work. It’s a difference in velocity, planning, and volume. When you are writing software on your own where you aren’t paid for your time you tend to be in far less of a hurry and yet produce 10x as much. As a corporate developer you are paid to hurry and complete tasks and in many cases with incomplete documentation, which is just writing code and sometimes guessing at what you need. When you are on your own success is measured in product delivery and feature completion, which is not just writing code.

Another major difference is communication. If you communicate poorly your open source software is dead on arrival. End of story. You should never have to guess at your business requirements, APIs, steps to reproduce defects, and various other things. The more you have to guess the more mistakes you will make. The only path to redemption is to communicate more precisely than those around you.

Perhaps the worst distinction is design by committee. Frequent long meetings just waste peoples time. The time that’s left over means hurry harder. A more productive direction is for some fool to sit a position of leadership and make arbitrary decisions. A wrong decision can be fixed, but wasted time is gone forever.

You can’t really explain this to a developer who has never written code outside the office because they refuse to believe what they have never experienced. The hurried low productivity churn is all they know.

[cutthegrass2]

> A wrong decision can be fixed, but wasted time is gone forever.

so true!

[_benj]

I was recently given a legacy project to work on. Two things happened, I made at least one big mistake that took 4 people and 3 days to fix on production. Second, I realized that I had a very strong resistance to reading somebody else’s code.

When I was forced to in order to correct my mistake I realized that reading the code would have been so much easier to begin with, and even exciting… kind of like a puzzle to be solved.

Trying to understand a project, starting with main, arguments, env variables all the way down to the part your are interested in gives SO MUCH insight not only into the project but into the company and their process.

Code don’t lie. It’s a hurdle to get past but understanding the project as a whole give so much insight (i. e. edge cases, hacks used in the past, etc.) and confidence when fixing a specific problem.

[schiederme]

If I read that correctly, I personally would give this answere:

I have the same problems and get into rabbit holes quickly.

After some research on the internet and in my past life (got fired twice this year /o\), I concluded to do a ADHD/ADD assessment. I got Diagnosed with ADHD.

The main thing that changed: I’m more aware of the mistakes I do and notice my behaviors early on and can mitigate the bad parts.

So for me the answere is simply: maybe try todo some online ADHD test and if it indicates a potential diagnosis, do a real one with a psychiatrist.

[templarchamp]

You are asked to explore and make modifications to software. Someone wants it quick. Fortune is on your side - atleast you know people(akin to explorers) who navigated before survived (which means the system did not cause blackouts). All you have to do is be hyperlocal and slap on the bandaid, chewing-gum and ducktape, whatever is handy. System is a product of its masters - your bosses. Sleep well!

[giantg2]

What kind of mistakes? That could make a big difference for the answers.

[100011_100001]

No one writes perfect code. The trick is catching errors sooner than later. Part of this is experiencing pain and self-correcting.

For example caching has burned me so many times that when I see an application doing caching I will triple check my solution because it might look good because it's the cache looking good, not your change, or vice versa.

In my opinion there are two approaches you can take.

Approach 1 - Wrecking Ball: Implement entire solution using dirty code. The point is to have the solution "working" and handling in the most likely use case. Then you start adjusting your code, abstracting, handling edge cases, dealing with error handling etc. This is like a depth first approach

Approach 2 - Radar: Implement the solution in layers. Like a radar scanner that goes from a center point out. You add code in layers, so first you get the inputs you need, then you do calcs, then work on errors. The key is test each layer, this is where unit tests become invaluable. This is a breadth first approach.

I am not a huge fan of pure Test Driven Development, but a hacky approach works well. I like writing code then testing. Now the test might be an automated test, or print statements, sometimes even visual.

Both approaches require a double check of what you have done. I am more of an approach #2 person. Mainly because my mind works like a weird neural network, I go depth then pull back and explore parallel avenues determining the best way to get to my target. Anyway, I digress.

The point I am trying to make is that regardless of your approach you have to test. Don't get stuck with test = unit test, but testing frequently and early is key. This can help with "2 days troubleshooting an error that you caused yourself"

The other hurdle you have is you are working on an existing project that you don't have experience in. The tribal knowledge is what gets you. Are you familiar with Cunningham's Law? To paraphrase, the fastest way to get an answer to a question is to post the wrong answer. Now something I have noticed is that if it's a Code Review, some people will just rubber stamp it, so they won't catch your errors and it will boomerang back to you. So I abuse human psychology instead. Mainly that people will pay attention if you use their names and ask for help.

It works even better for natural pessimists, but what I do is describe my code in words. Let's mock this...I'm going to use Groovy, mainly because I was Code Reviewing this change the other day.

    def calculateDuration(start, end) {
       long elapsedTime = end - start

       Long second = (elapsedTime / 1000).longValue() % 60
       Long minute = (elapsedTime / (1000 * 60)).longValue() % 60
       Long hour = (elapsedTime / (1000 * 60 * 60)).longValue() % 24
       Long remainderMillis = elapsedTime % 1000

       return "${hour}h ${minute}m ${second}s ${remainderMillis}ms"
    }

If I was writing the code, I would have pinged someone and said something along the lines of:

Hey XYZ, I need your help.

I am writing some code to easily be able to calculate the duration of things. I assume milliseconds as input, and a start and end time will get passed in.

Then I use that time to do an 'end - start' and figure out how many hours, minutes, seconds and milliseconds based on that result returning it as an "Xh Ym Zs Kms" string.

Anything I might have missed? Can you think of any edge cases that I might know about?

Thanks,

-----

Then if the discussion progresses I will point them to my specific branch. Programmatically we could debate the use of Long vs long. Or typing the input parameters and return or not.

The thing is this "solution" missed a key aspect. Milliseconds can't be assumed as input. He had tests, but all his tests were using milliseconds. If I had rubber stamped it as a code change, within three days we would have started getting messages from POs, and they would show up in Kubernetes namespace metadata, which if you don't know how things connect to each other, it would be hard to figure out why the metadata in a pod suddenly changed.