Live data from Hacker News

Always Do Extra

bennorthrop.com

51–60 of 129 posts

Re: Always Do Extra

#51
post #41

Oh, God. This sums up one of my coworkers. Smart, productive, generates lots of LOC that almost always do the right thing, but oh my God, the "Extra." Dig into any of his code and you'll always find something Extra, like the front end is built in SomeObscureLanguage.js, or the business logic is expressed in a custom DSL implemented by macros, or some piece of the app seems to be mysteriously absent, until you discove…

Have you considered he just might be prepping for his next job?

How's the pay/option package at your current place?

Re: Always Do Extra

#52
post #41

Oh, God. This sums up one of my coworkers. Smart, productive, generates lots of LOC that almost always do the right thing, but oh my God, the "Extra." Dig into any of his code and you'll always find something Extra, like the front end is built in SomeObscureLanguage.js, or the business logic is expressed in a custom DSL implemented by macros, or some piece of the app seems to be mysteriously absent, until you discove…

Justifying coding choices using a single SE principle ignores the others you have to weigh it against. Everything is a trade-off, or else the code could just write itself!

Re: Always Do Extra

#53
post #41

Oh, God. This sums up one of my coworkers. Smart, productive, generates lots of LOC that almost always do the right thing, but oh my God, the "Extra." Dig into any of his code and you'll always find something Extra, like the front end is built in SomeObscureLanguage.js, or the business logic is expressed in a custom DSL implemented by macros, or some piece of the app seems to be mysteriously absent, until you discove…

Yikes! That'd drive me crazy.

I'm reminded of the YAGNI ("you aren't gonna need it") principle. Sounds like your coworker could apply it more.

Re: Always Do Extra

#54
post #41

Oh, God. This sums up one of my coworkers. Smart, productive, generates lots of LOC that almost always do the right thing, but oh my God, the "Extra." Dig into any of his code and you'll always find something Extra, like the front end is built in SomeObscureLanguage.js, or the business logic is expressed in a custom DSL implemented by macros, or some piece of the app seems to be mysteriously absent, until you discove…

Have you considered he just might be prepping for his next job? How's the pay/option package at your current place?

He's the longest-tenured developer at the company by several years (and many others have come and gone in the meantime.) He knows he has a good thing going and would have to shape up if he went anywhere else. I'm feeling like a failure trying to influence him, but we finally have technically engaged management, which he's never had before, so maybe the clock is ticking for him.

Re: Always Do Extra

#55
post #41

Oh, God. This sums up one of my coworkers. Smart, productive, generates lots of LOC that almost always do the right thing, but oh my God, the "Extra." Dig into any of his code and you'll always find something Extra, like the front end is built in SomeObscureLanguage.js, or the business logic is expressed in a custom DSL implemented by macros, or some piece of the app seems to be mysteriously absent, until you discove…

That's a bad "extra".

My advice to junior engineers is "take one step extra".

Write that test that you should have written. Cover that one edge case you know you blew off. Write that cleaner error message that you should have done in the first place. Pick off a single "FIXME" in the code. Write that comment explaining "why" you just wrote the code this way.

The "one step" is the important part. Everybody can take "one step" with just a little effort. But "one step" compounds.

Eventually, that "one step extra" becomes your normal and the next "one step" is a little further. Repeat. Repeat. Repeat. Suddenly, your "one step" is stacked on "10 steps" that are now habitual. Repeat. Repeat. Repeat. Suddenly your stackup is now "20 steps". Etc.

And, suddenly, a couple years later, you find that you are much better at what you do than practically everybody around you.

Re: Always Do Extra

#56
post #41

Oh, God. This sums up one of my coworkers. Smart, productive, generates lots of LOC that almost always do the right thing, but oh my God, the "Extra." Dig into any of his code and you'll always find something Extra, like the front end is built in SomeObscureLanguage.js, or the business logic is expressed in a custom DSL implemented by macros, or some piece of the app seems to be mysteriously absent, until you discove…

This, I think, is the pitfall of doing your own thing. When I was younger I did a lot of extra and I suppose it went fine. I did expand our features and I added more functionality and sometimes it ended up being useful. But the truth is that I'm not a strong enough engineer to see what extra I could do that would consistently add value.

I think a lot of people who find success in doing extra are either lucky or at a level above most engineers. I think a lot of the horror stories that you find on dailyWTF and other sites are the result of less skilled (or more isolated) engineers doing extra in a way that makes sense to them. Doesn't mean you shouldn't do it - but I wait longer and am more cautious when I do it now. I think it's more helpful overall.

Re: Always Do Extra

#57
post #40
post #34

Earlier quoted context omitted.

That will work well .... for a month.

It's been done. In one of his books Feynman describes how the scientists on the Manhattan project would "estimate" their results as what they had accomplished in the prior quarter. It's a bit messy to get it started, but once you've got a cadence you can always maintain that three months of buffer. Edit: Now I'm thinking about what kind of tooling I'd want to make the process seamless.

It had been done in sentence as quoted from the post as well ("hey, I did some research on X"). GGP suggested waiting for some time purely for psychological purposes. But yeah, I don't think it matters a lot after a while either.

If the management doesn't like it, they'll figure it out that if you keep coming up with these then you must be spending time on them - continuously. :)

Re: Always Do Extra

#58

> It's never something we need to hide, but instead it's something we're eager to share with our teams - ala "hey, I did some research on X, and maybe this is something that could be valuable for us to try". I'll give good odds that in most shops, if you pull this line more than a couple of times, your management chain is going to decide you aren't picking up enough work in sprint planning...

I think the author needs to elaborate more on "extra". I've been on both sides and I know what Ben is referring to. This isn't about showing off so that your boss thinks you're not busy. I think OP is trying to encourage people to care about their job to the point where they want to do it better. I think what he means is: doing extra is insurance. It is knowing your job more than just punching a clock and getting the…

Sorry, I’ve been doing your ‘extra’ for years. While it earns you kudos and respect, it rarely gets you promoted, if ever. Playing politics on the other hand is lot more successful.

Re: Always Do Extra

#59
post #40
post #34

Earlier quoted context omitted.

That will work well .... for a month.

It's been done. In one of his books Feynman describes how the scientists on the Manhattan project would "estimate" their results as what they had accomplished in the prior quarter. It's a bit messy to get it started, but once you've got a cadence you can always maintain that three months of buffer. Edit: Now I'm thinking about what kind of tooling I'd want to make the process seamless.

Use a second ledger, like the mafia
Post reply on HN