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

I would echo the perfection/artist thing, I've known a lot of engineers and ones who are perceived as slow, are often also setting a really high bar for their code. The learning for those engineers is to develop an understanding of how good is necessary, and how good is ideal.

If you find yourself rewriting your code a lot, consider using a technique that Pixar uses for making digital films which is they work on them on sections until they are "good enough" and they put that part aside with the label "Good enough, could use improvement", until they get everything in the can, now the film is completely "done" but all of the sections can use improvement. They order those sections from most impact to least and start working through them. At any point they could just print the film and ship it, but the longer they work the better it will get. Often there are other parts of the pipeline that have to be aligned and so they will get a chance to knock off a bunch of improvements before it actually ships.

I can +1 the "good enough" approach. I write code such that it works. When I get the urge to change something (and that is a lot), I change what I have to for it to work and make a TODO comment. I rutinely parse the TODOs and reevaluate them. When the product reaches v0.9 (i.e. only bugfixing allowed, no new features) I start to look at the TODOs and work on some of them.

I generally agree that it is important for a software engineer to be able to identify the quality/speed desired by the client/manager. However, I think this advice needs to be applied cautiously:

> If you find yourself rewriting your code a lot, consider using a technique that Pixar uses for making digital films which is they work on them on sections until they are "good enough"

This approach works for features where side-effects are isolated to a small part of the system (eg. UI changes). For anything major, it is worth doing right the first time. eg. A library on which other software is constructed. The mastery is in weighing up the scope and likelihood of rework that might be required in the future.

I've only seen advice so far on how you can "get faster", but I believe the real issue here is that you are being perceived as being slow by a manager who might not know the value of what you are doing.

I had a manager tell me I was slow at one of my last jobs as well.

A few months later, I was having trouble convincing her to give me a promotion/raise. I knew I was doing the same amount of work as everyone else, if not more, and I was fixing a lot of bugs caused by developers 2 or 3 levels above me. Our 1 on 1 meetings consisted of me listing the reasons why I deserved a raise, and my manager telling me no, but never a good reason why. She even read me the guidelines for what the company looks for in engineers at each level, and I was doing all of it and more, but still no raise.

I ended up quitting (not just because of the pay), and taking my skills to an awesome new job where I was considered a top engineer, and I'm really proud of everything I got done there. The new company gave me a raise when I asked for it because they valued me more than my previous company.

My personal advice is to look for a new job where you can apply your skills where the company needs them, and make a good impression from the beginning. The added bonus being that you'll be able to negotiate a higher salary with the new job as well.

This struck a chord.

[Edit] I had an essay explaining why, but long story short... it's just that I had the same experiences on my old team as you described, so I left out of frustration for what I consider my dream job. Now it feels ruined because I can't really start fresh, and I moved halfway across the country to take this new role. How are we doing on time travel? Any progress?

Indeed; one of the very most frustrating jobs I ever had, my last at a Lisp company, ended up "pitting" me against a very junior programmer, who was a flurry of obvious activity, including lots of debugging. I put in less hours (but still a lot, it was a pre-launch startup), often took a nap in the afternoon, was much quieter in a way, only asking questions about the code base and e.g. asking for one procedure to be coded in assembler to make the editor we were working on fast enough, etc.

My output of working code and functionality was a lot higher, I removed entropy from the code base (the other guy at best didn't add a lot), and ended up being demoted and then quitting in disgust. In vague mitigation we were reporting to the 3 founders and friends who'd all gone to the same school and this was their first attempt to manage others, but....

I don't know if your situation is akin, but it does sound like there's, realistic or not, an unbridgeable gap between you and your manager(s), and its time to find another job with a better fit before the company takes worse actions.

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.

This might be a sign that you have a tendency towards perfectionism. This is not the worst problem you can have and is manageable.

I suggest working on new features as WIP pull requests and have others review the code when it's feature complete. Not when you deem it ready. Then you can gage from others where you are spending unnecessarily much time, using quick learning cycles that will teach you to be faster without sacrificing quality to a large degree.

In bullet points because I have almost the same problem. Here is what helped me:

1. talking with my manager more

We have perf reviews every 3 months, and the review has 1-2 month delay. I recieved in spring a report that my perf in winter was mediocre. And then I recieved in summer that my perf in spring is worse. And I didn't think it detiorated, so I came to him and asked "Hey, how did it get worse past quarter, because I thought I am getting better at this." And he told me about concrete project that he thought shold have taken a week or two and took month. And that after I finally finished it, the rest of my work-pace this quarter looks better.

2. identify the problem with your manager

For me it was, that I am able to get stuck on a task for a several just reading all the error logs without asking others for help. I know that some other team-mates had similar problem, so we introduced daily standups and more over I do my best to track whether I am trying to get unstuck more than one hour and if so, ask around for help.

3. I kinda embraced it

Everybody on the team knows that I am the one with wife and a kind that gets stuck on his work often :-) So, on meetings I allways ask after I have new task "Who should I bug if I get stuck?" and they know, that I am at work at 8 am sharp, but hell or high water at 5 pm I am already playing at home with my 1y old :-)

So, just talk about this with your manager. And try to fix your biggest pain points (like I try to to with me getting stuck :)

Every hear of "fast, good, cheap: pick two" ? https://en.wikipedia.org/wiki/Project_triangle

You manager won't tell you directly, but they're asking you for crappier code, faster. Give them what they want but also cover yourself by sprinkling the codebase with TODOs. And in your updates on tasks when you're done mention areas for future work not yet done.

Most developers who churn out code tend to churn out bad code.

Also I hate to say it but politics and image is a large part of any job. My honest advice would just be to find a new job where you're appreciated.

Are you actually slower than coworkers in an apples to apples comparison? Normally when I see things like this, it's usually comparing developers having a different definition of "complete". One will write the code, the unit tests, the e2e tests, and the documentation before saying the task it complete. The other, trumpets completion once the code is done.

If you're actually slower, I'd start keeping track of where my time is going. Are you spending too long imagining all possible scenarios of a feature? Taking two hour lunches and coffee breaks every hour? Many hours spent in meetings? Wasting time building a "super generic" solution that isn't necessary? Spending three days writing tests for a feature that took 5 hours?

If you don't feel like you're actually slow, it's just a problem of perception. I'd take some higher visibility features and crank them out, working the extra hours if necessary. I'd rather kick the stigma than deal with that anchor around my neck. Tread carefully with this strategy as it can be a double-edged sword and increase expectations and workload.

There are definitely ways to get faster. As long as you are paying attention and care about your work, you'll naturally get faster as your career progresses. But making a concerted effort pays off as well.

One thing that would eat up a lot of my time is trying to automate every last thing, and make it reproducible. I would do it with Python. I still believe in this goal, but I do things with shell and a smattering of Python now, which is way faster and actually more elegant. Shell is an unbelievably productive tool! Though it takes time and effort to learn properly.

Another thing I do is write down everything I plan do in a Wiki -- down to a very granular level. Always keep the end goal in mind when writing out the steps. It helps think of short hacky strategy first, in addition to the "right" strategy. Frequently the shortcut will give you some new information that changes the "right" strategy, or it might be good enough by itself.

Since it sounds like you have the tendency to do things right (like me), you won't fall into the trap of shipping sloppy and broken code like others (i.e. the state of the software industry). This is a trick to balance your natural tendency. You want to learn about "unknowns" earlier to reduce risk.

The third thing major is unit testing, though it sounds like you're already doing that. For me, it makes things faster, because I can switch between many projects at once. I think of it like putting state in your brain down into executable code. It takes me very little time to pick up where I left off on old code now, whereas I see a lot of people struggling to load the context into the brains. However, I also tend to write tests in shell now, which is way faster than lots of complicated unit test frameworks.

Great advice here! One thing (slightly OT) - what do you use for unit testing in bash? That sounds like it could be really cool, though I currently write my tests in Coffee so I'm a bit skeptical as to the productivity gains.

Technically couldn't you just write a separate bash script that tests the exit status or return of anything you are scripting in bash? Feels like bringing in any other "framework" would possibly just get in the way?

I think the GP was talking about tests written in Bash, not tests for Bash code.

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.

So it looks to me like the main case you use bash scripts for is integration tests, and you simply check for whether there is an error (as opposed to checking the output). Do you run any sort of assertions on the resulting data (for instance, POST {x} followed by GET {x} should return {x})?

As much as I appreciate minimalism (and the idea of tests in Bash do seem alluring), for anything involving large JSON structures or wanting to know what specifically about a particular test run went wrong, it seems like Bash would fall short. I'd love for you tell me I'm wrong though.

I do smoke tests in bash for sure, but writing exhaustive test cases may be better done with unit tests in the language.

You can do something like:

  curl http://localhost/ > actual.json
  diff -u actual.json <<EOF
  {"expected": "json"}
  EOF
  check $? -eq 0

Where check() is a simple wrapper around "test". Or you could write a 2 line "check-eq" function that does the diff too, and that would get you pretty far.

I guess the meta-point is that bash is "just enough". My goal is to deliver working software, and a smoke test written in 10 lines of bash can help tremendously (i.e. reduce trivial errors that cause havoc with a deployment.)

I actually started a bash test framework, probably 2-3 years ago. But honestly, I haven't needed it as much as I thought. Sometimes I copy and paste some functions like "check" into new projects. It ends up being different for each project, so it's perhaps not worth generalizing.

The point is to be lazy, and put off all non-essential tasks, and writing a general test framework for bash proved to be something non-essential. There are existing bash test frameworks out there for sure, but I haven't really found the need to check them out.

Hope that helps.

It does actually, thank you very much for taking the time to reply in such detail. Bash testing (or rather, zsh in my case) is definitely something I'll have to consider moving forward.

These are almost the same things I did. Chubot, can you show us some good examples of tests written in shell scripts?

Were the deliverables fixed by the management or you were responsible for the estimate? If you are the one who consistently underestimates the time, maybe that's a legitimate point.

Ultimately, it is stupid if they'd favor giving a project to an intern over you despite your results/writing maintainable code etc. The company will pay for shit code accrued over time.

I don't know enough to truly speak on this, but it honestly sounds to me as if you are someone who is very rational and thinks before acting. If this is a detriment to your employer...I don't know what to tell you.

Slow guy here.

First thing to check: do you want to make it more beautifull than you should? Sounds to me you want to release good products. But in my experience this can also lead to scope creep.

Then there is stable code. I also am one of the slowest engeneers but my manager knows this will result in less work after the deadline.

So my advice: stick to what should be done to keep the deadline and prove your code saves time after the deadline.

It's not good to work for people who see you as a liability. Consider working for someone else.

If you are working 12 hour days you might want to get out of there, unless if you are making 150k then stay. If you are making around $80k ish then run.

Another option is if you are making enough, you might want to outsource some of your work. Get multiple people working on any tricky problems so you can tie up the loose ends.

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.

I don't know if I've ever been "slow", but I've definitely gotten faster over the years. My personal measure of how experienced I've become as a developer is the number of problems that I treat as a hash table lookup (vs those I need to actively debug). Given that, there are a few possible causes for your so-called "slowness".

If you spent 4 years on the same team, it's quite possible that rather than getting 4 years' worth of experience, you got one year of experience 4 times over - by not constantly being exposed to new classes of problems, you haven't actually expanded your ability to solve problems by a significant amount.

Another cause is that you may not put enough thought into the type of work you find yourself doing. There's a fabulous talk by Rich Hickey (http://www.infoq.com/presentations/Design-Composition-Perfor...) where he compares software developers to improvisational jazz artists. The gist is that Coltrane didn't just get up on stage and play music that magically popped into his head: he practiced, and tried stuff out, and then on stage he composed little things that he already knew worked into a single performance. Software is much the same way - by playing with new things in your spare time, reading about different patterns and libraries, and thinking about the types of problems you face day-to-day, you're building up a huge library of small solutions that you'll compose into software at work.

Reading HN every day is a good start. I like to use HN as a source of inspiration and a place to discover things to learn about. Were it not for browsing HN pretty much every day, I wouldn't have discovered most of the things to which I attribute to my growth as an engineer over the past few years. Certainly, I wouldn't have grown much if I didn't actually investigate those things, but it's great to have a constant source of new "known unknowns".

The degree to which you can put any of this advice to use, is of course, entirely dependent on how much time you're willing to devote to getting better at building software. Aside from spending time with my fiancée and son, I don't do much other than what I've described above. As a result, I'm fairly one-dimensional, but I'm more interested in writing great software than being interesting at dinner parties, so it's an acceptable tradeoff for me (the other result being that I'm told I'm pretty damn fast at writing good software).

TL;DR practice, read, practice, read, practice.

> Reading HN every day is a good start.

Just be careful with that. It can really suck the time. I have a problem that I am reading too much and writing/working less since I discovered HN. I am almost seeing it as addiction.

It absolutely is. If you're interested in why, I recommend Nir Eyal's (great) book, Hooked: How to Build Habit-Forming Products. Basically, our brain gets addicted to "variable reward systems" (Facebook, slot machines, news websites) because it gets excited when it finds something interesting/entertaining. Not everything is though (this is the key part), so when you finally do find something good your brain gives you a dopamine rush, which addicts you. I won't pretend that I don't struggle with this addiction myself, but I've found having genuinely interesting work really helps - I read HN at work quite rarely at my new job.

I don't know enough about your situation, but you should know that A) managers are just people and make errors in judgements and B) sometimes managers exaggerate stuff like that to get more from employees (12h days for instance).

For A, you could pull a bunny out of a hat - finish a project early (as early as possible) and make sure it is noticed (but don't brag about it). For B - sometimes you have to compromise, and sometimes you don't have to. Can you find another job? Do you want to? Can you stand up to them? Depends on your situation...

Last but not least, "slow" is not the same as "not meeting the deadlines". Are you meeting them? Make sure this is noticed! I would rather have a "slow" member in my team who can reliably deliver good results in time than some "hotshot" who can delivers tons of (unusable) code in very fast time...

Bottom line: in companies what should matter is how much you contribute. Just make sure others notice it too.

> Before, I think my manager saw me as ready. Now I think she sees me as a liability.

Did you talk to her about this? Did you ask her what can be done? This entire situation is painted that you're the one to blame. There are 2 sides to every story, your company can set realistic expectations. It sounds like your work is solid and that people respect you, but that your management has unrealistic expectations about your velocity. A compromise can be reached.

> PS: I'm getting married next month. Will I have to choose between my marriage and permanent 12 hour days?

Yes, and your marriage is more important. Unless your job is incredibly fulfilling and meaningful, it's not worth working 12 hours a day.

The high value project is a great place to find the parts that require the least amount of effort on your part but will have the highest value to the company and deliver those first. As an engineer this feels like "cheating". It's not, you are being prudent.

I just finished reading The Effective Engineer by Ed Lau and highly recommend it( https://www.theeffectiveengineer.com/book ). It covers both concrete (like keep a daily log) and more general ideas(e.g. your work is measured by the value it produces for the company, not the effort you put into it).

Sorry, but I just can't take this book seriously.

The author uses this incredibly annoying marketing copy associated with get rich quick schemes. It comes across as manipulative and patronizing. He even sells optional pro and master packages with the book.

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

QA: practice, practice, practice.

PSA: no - You should NEVER choose work over your private life. If Your current boss ask You to choose between it - change the job.

Could you describe on the technical capabilities of your current and past managers. How the team members view your managers? Does the managers are only interested in getting the work done and not bothered to look at implementation ?

Collaborate with your manager on more detailed work schedules. Ex: if you do week-to-week deliverables, switch to day-to-day. They'll have a better notion of expected cadence.

First step is acknowledgement. Seems like if you figure that out you can figure out how to speed up a bit (without compromising quality too much).

SDE I, SDE II... Microsoft?

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