Ask HN: Slow engineers, did you get faster? How?

same denomination is used in Amazon as well, and probably other (big) companies as well. Not sure if it's indicative of Msft.

The two biggest things that jump out at me here:

- you feel like you're performing well, but are being told you're not up-to-snuff

- you're already worried about working 12 hour days and having to sacrifice your work/life balance with your spouse-to-be

Aside from valid comment about learning to move quicker, perfection is the enemy of good, etc etc.. it seems like you need to evaluate your working situation as a whole.

You believe that you're performing well. Your code is stable, there's top-down acknowledgement that you're pushing towards tested and maintainable code. Yet, you're being told you're... slow. Now, maybe that's true. All engineers operate at different speeds. With a proper manager, though, assuming you're not going amazingly slow, they should see this and understand it. If one of your best qualities is being pushed as one of your worst, then management is doing you a disservice, instead of being able to position you get better.

Also, consider that you're working 12 hour days. I could, with a little hyperbole, say that you're already married to your job. :) This is already a weird situation. Are you part of an on-call rotation? Is it a busy season? Does your company give out bonuses frequently to acknowledge this extra work being put in? Consider the psychological and physiological effects of being worried about what your manager thinks of you, getting married and, potentially, the traditional planning rigamarole that goes along with it, along with physically sitting at a computer for 12 hours, all while dealing with the other things normal humans might have to deal with on a day-to-day basis. It's a corrosive situation. It's a negative feedback loop.

What I'm saying, if anything, is that it sounds like maybe you're ready to explore other opportunities. Changing jobs isn't simply for making a salary jump. There are a lot of great companies out there who value the qualities you (not the general "you", you) possess and have the right management to make sure that your greatest strengths stay that way, and are applied beneficially without being perceived as a risk or liability. There are also companies where working a normal day, without extended hours, is not only normal, but jokingly enforced... because many companies do actually respect work/life balance. :)

First, never sacrifice personal satisfaction and happiness for a job. It will never work out well in the end and you will regret it later in life. Jobs come and go (there is very little company loyalty in either direction now a days), family shouldn't.

Second, I will admit to being a douche earlier in my career when managing projects and wanting faster production. What changed it for me was an older engineer who was SLOW; he made no apologies for it and kept pointing out to me that yes, he took more time than many others. But many of them also had to come back 4-5 times to fix issues in the same code while in his the amount of rework was minimal if at all. So my perception was he was slower, but reality was he was faster because in the end he spent fewer man hours on any given problem.

Once I learned that, mostly thanks to him helping show me, I changed how I viewed everyones productivity. His approach was not defensive, not belittling, not condescending and not ego driven. Instead he approached me and said he understood my concerns but thought it would help me to understand the man hours being spent versus just the deadline. Not that the deadlines weren't important, but if you make a deadline and have to rework code constantly for the next 2 weeks to fix preventable errors then did you really meet the deadline?

So your answer out of this, is try to change the perception from your slow, to you spend less man hours (time doing rework) being more productive and writing better code. It won't always work, but frankly if it doesn't that isn't a team or company you want to be apart of. If they value speed over reliability and more man hours over fewer then they will just work people to death and treat them as disposable. One other point, if the team or company is a point, shoot, aim type this argument won't work and they will only value speed not accuracy or reliability. In that case, look for other work or another team within the company that has different values.

Hm so when I am writing web servers, I typically have a bash script that simply does curl on a bunch of URLs. I just run it by hand and make sure it stops on the last failure with 'set -o errexit'. I divide it up into bash functions so I can run the set of tests I want, and then string them all together with a top level function.

It's ultra-minimal, but that is the point. My job is to deliver working software (relatively quickly), not necessarily beautiful tests.

And I actually should say I do "system tests" in bash, not necessarily unit tests. But I START with system tests. My workflow is now like this:

    - write SYSTEM tests in bash first.  This helps me plan what I want to get working.
    - write the code (It's like TDD but with system tests)
    - sometimes there is some complicated logic I need to test.  Then I switch to unit tests in Python, JS, R, C++, etc.
    - when I fix bugs later, I tend to reproduce it with a system test.  This makes bug fixing easy.  Then I write a unit test to zero in on the broken part, and sure it never comes back.

I probably save 70% lines of test code, while delivering the same level of quality. A system test can be fast and can substitute for a lot of unit tests, and it helps you not ossify your code structure too early.

I don't have an example of that online, but you can see 880 lines of shell in the root dir here: https://github.com/google/rappor

Granted, this is more like scientific / batch code than web / backend stuff, but I assure you I follow the same strategy in the latter case. It's basically using Unix as leverage.

One thing I would notice about the scripts is how the last line is "$@". That runs the function $0 with the args $1 ... $9. This is a very handy trick that helps keep everything modular and independently executable.

I use shell scripts for all these things:

    - building code (in C, JS, Python, or any language)
    - testing code (running unit tests in multiple languages, and also system tests, constructing test data)      
    - deploying code
    - sys admin; setting up servers (e.g. setup.sh in the repo), backup, managing log files
    - building docs; making static web sites   
    - building config files and data files (e.g. lists of URLs)

My assertion is that, combined, these things take up MORE time than actually writing code! If you can speed them up, you will be more productive at "coding" overall.

In addition, using the same tool (bash) for all of them makes you more productive (once you have climbed the admittedly substantial learning curve). I'm not a fan of all these language-specific build tools now. I don't even use make that much; my first choice is bash!

Here is one concrete example of shell minimalism, which helps you get things done faster. Think about the common situation of having a {star}_test.py files in many directories, and you want to run them all together as a test suite.

I am embarrassed to say that at one point I spent 2 or 3 days researching and implementing some kind of Python test runner (this was over 10 years ago). I think people do it now with "nose" or something.

Here is my preferred solution:

find . -name {star}_test.py | sh -x -e

Or if you need parallelism, something like:

find . -name {star}_test.py | xargs --verbose -n 1 -P 10 -- sh -c

({star} should be asterisk; HN is not letting me escape those)

That's it. It doesn't necessarily give you pretty output, but it's what you need to deliver working software. Add one line to a bash script and be done with it, rather than getting distracted by yak shaving.

The shell scripts may not look that impressive until you think about what they actually save -- what common alternatives are. One line CAN actually save you 2 or 3 days of time; this is not the only time I've experienced this.

The overall point is that I used to spend a lot of time on tooling and automation (yak shaving), because I wanted a certain level of code quality and iteration speed. But now I do most of those things with a small, sharp tool -- bash -- and I find it saves a lot of time. I get in the zone and don't get distracted from the main task.

The horrible truth is that regularly writing crap code that bursts into flames and then making flashy, heroic efforts to put those fires out is the fast track to the top. Taking the time to produce quality artifacts feels really good, but it is a rare company indeed that can recognize the value in this.

I'll echo other commenters and say that if you have this stink on you and/or you're company isn't appreciating your work, it's probably time to move on (esp after four years). You can't fix companies--all you can do is find a better match.

As for myself, I'm a slow engineer. In my decades, if anything I've gotten somewhat slower. At the same time, my quality has risen dramatically. I write bugs rarely enough these days that I've gotten quite rusty on debuggers; usually a few judicious print statements (at most) will point out the problem.

The key is that I design and write code that has a "shallow" bug surface. When bugs happen, they're almost never those deep-dive kind that lead to a week-long bug hunts.

Don't sweat it too much. Keep sharpening your axe, and if you go six to twelve months without feeling your work is appreciated, run.