Ask HN: Slow engineers, did you get faster? How? • Hacker News Board

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

#21

Post by shawnps » Mon, Jun 22, 2015, 6:33 AM UTC

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.

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

#22

Post by wwkeyboard » Mon, Jun 22, 2015, 6:33 AM UTC

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

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

#23

Post by notduncansmith » Mon, Jun 22, 2015, 6:37 AM UTC

zachgersh wrote: post #15

notduncansmith wrote: post #11

Earlier quoted context omitted.

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.

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

#24

Post by insulanian » Mon, Jun 22, 2015, 6:42 AM UTC

notduncansmith wrote: post #9

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…

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

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

#25

Post by hvidgaard » Mon, Jun 22, 2015, 6:58 AM UTC

ChuckMcM wrote: post #14

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…

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.

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

#26

Post by notduncansmith » Mon, Jun 22, 2015, 7:00 AM UTC

insulanian wrote: post #24

notduncansmith wrote: post #9

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…

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

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

#27

Post by bottombutton » Mon, Jun 22, 2015, 7:01 AM UTC

shawnps wrote: post #21

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…

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?

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

#28

Post by lmeyerov » Mon, Jun 22, 2015, 7:07 AM UTC

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.

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

#29

Post by bottled_poe » Mon, Jun 22, 2015, 7:37 AM UTC

ChuckMcM wrote: post #14

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…

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.

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

#30

Post by blub » Mon, Jun 22, 2015, 8:35 AM UTC

wwkeyboard wrote: post #22

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…

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.