[dkarl]

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 discover it's injected via a custom plugin for the build tool.

Everything he does can be theoretically justified by DRY or some other principle of software engineering (it's almost always DRY, and when it isn't, it's type safety) but the payoff for the extra complexity is always an order of magnitude away. Like, the custom build plugin would make sense if we had a bunch of apps that were structured the same way, but we only have one. The custom DSL for the business rules would make sense if there were a hundred rules, but there are only a dozen or so. Using SomeObscureLanguage.js might theoretically (for the sake of argument) give us an edge that would be worth it if this were one of our reputation-critical consumer UIs supported by dedicated team, but it's an internal tool, and the bugs never get fixed because there's only one person who knows SomeObscureLanguage.js, and he's always doing something more Important.

I don't disagree with the article. Extra will distinguish you more than More, and if done right, it can speed up your team. Just be sure that all the Extra you do makes your teammates Extra productive, and that you aren't adding Extra burdens that slow everybody down and make software development Extra responsible for the slow pace of launching products for new markets.

[bsder]

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.

[indymike]

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

Yep. This is exactly the right way to go. Another great extra: One of the best devs I've ever worked with would find one bug at the end of the day, every day, and kill it. He'd pick based on how much time he had. One developer, killing one bug every day kills over 260 in a year. Oh, and as the bugs die, development accelerates because so much less time is spent on working around bugs.

If you work in an organization that doesn't value and promote those that do extra, find somewhere that does. Work doesn't have to suck... especially developing software.

[aeturnum]

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.

[dkarl]

I agree. I think doing Extra for personal development is rarely aligned with job performance, and you have to be very, very good and conscientious about creating that alignment. More often people get away with it by tanking the productivity of their coworkers and making the business increasingly reliant on their personal productivity. But to do this you need weak or absent technical management.

I think doing Extra, More, or "Nothing" are all fine choices, if by "Nothing" you include spending time on family, community, health, and non-professional education. For professional advancement, I think "More" is a fine choice if you have good management. Management should have the perspective to appreciate you making the right choice for the business. If they don't, well, in that situation, I find that advancement depends on selling yourself to people who only care if you're delivering good news for them and can't appreciate anything else.

[ornornor]

I read that graph differently where doing the work + more/extra/nothing is your 8h day. And so if you do the work + any of these it will amount to 8h. If you do nothing, you’ll still be stuck at the office anyway because if you do the work and leave early you’ll be asked to do more since you have leftover time. You won’t get to spend that time on your family.

[dkarl]

If you're working from home and getting your job done to the satisfaction of your employer in six hours, I think you can do what you like with the extra two hours. You may need to be available to your coworkers, but the rest is up to you.

[aowen]

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.

[Zababa]

My understanding is that you should use Extra to increase the size of your toolbox, but still use them only if they make sense. For example, I recently learned about the different kinds of maps in C++ while going through a part of the codebase that uses them heavily. I didn't use that knowledge directly though. Maybe one day it will come up, maybe it won't. When modifying old code, I try to have a good reason when changing the way things are done. If I'm doing something fancy, I usually try to confirm it with a collegue first.

Edit: another good example of Extra would be to build useful tooling for your codebase. It's usually higher-level work.

[pc86]

All of the examples in your first paragraph seem like things that should have been discussed with the team prior to development, or at least as part of any sensible code review process.

[verinus]

This reminds me of an excellent chapter in "Software Design Philosophy" by John Ousterhout about complexity- I think he names this accidental complexity.

It put a finder on an itch I had: that we tend to overly complicate solutions to a degree where we can't handle systems that combine these solutions as our brain can't hold all overly complex solutions...

In my opinion maintainability of software is by far the most important goal in production type software!

[908B64B197]

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

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

[dkarl]

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.

[_bfhp]

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!