Always Do Extra

This is true. Too many developers out there that think their job is to do what they're being told. It's the same type of developer that will then go to one of the Stack Exchange type of websites and complain that their boss isn't giving them time to refactor or write unit tests.

They don't give you time because they expect you to do so on your own accord. It's part of your job description. Another part of your job description is to make sure your manager is too busy managing, and doesn't have the time to micro-manage your time.

If they have enough headspace to tell you NOT to write unit tests, they aren't effective leaders.

that said, there's a difference between refactoring and rewriting a thing in a different language. At this point in my career, I'd be VERY hesitant to do the latter. The time spent in a rewrite is better spent refactoring and updating the existing codebase. It's just not as sexy on your CV.

> never feel like they're doing extra, they feel like that is part of the job.

That's the wrong way to look at it - "do extra" is not for the job, it is for your skills.

>> so Extra is what helps us broaden ourselves beyond just what's useful on our narrow project

Researching a new way of doing things is not about doing what is in front of you, it is to make use of the time-resource you have while you're in context. The article does mention it in passing, though it might not be clear that it is not "do the work better" (in more maintainable, more scalable ways), it is "become better at working".

Trying something and not being hurried is how the "learn by doing" people learn.

>> find their way into roles where Extra is their Normal Work, and we call these people Architects

In the article, I think that's a mislabeling of what a Principal engineer should be doing - the Architect's job is pretty much to talk to other architects constantly about what the Principals are doing with their "Extra".

"Team X is rewriting their jobs from Lambda to Batch because this package is over 50mb" would turn into a "how hard would it be to split it into -lib, -bin and -debuginfo packages?" - someone would spent their extra and tell me "wait, but we're shipping the .a and .so in the same -lib - this is a 900k .so".

People who get into tech tend to get nerd-sniped like that, but more accurately also enjoy working on a "solve a problem, not really a deadline" work. The Golden rule is to never take credit for someone who figured it out, just because you sent the email asking about it. Keep a set of notes of stuff that spontaenously happens and note it in every promotion review you write & it does eventually catch on that working on a 2-day jog like this is going to pay-off.

If you follow this path, I think it's important to remind yourself that you're doing extra, otherwise you might just forget that that's one thing that separates you from many of your peers. It can be an important point of pride and continuing growth.

100%. If your lead isn't baking in time for interleaving steady foundational work, then it's probably a consulting one-off where that's the receiving org's problem... or it's time to look for a more productive environment.

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 sprint done before going home and drinking. It is engaging in your task deeply so that you can do it better, whether that means architecting defensively, or being more nimble when something blows up because you went one step further and know it better.

I've had programmers that look at their sprints, see they have to do Task A, B and C, and do exactly tasks A, B and C. No more, no less. That's fine. That's better than doing task A and being overwhelmed (or whiny).

But some programmers do A, B and C and then look it meta-task D that is a "why A B and C?" task. They then see those tasks in a more holistic fashion.

No one ASKED them to do that. They took the initiative.

Those folks get promoted.

No one gets promoted from doing A, B and C and that's it. That's called status quo, or simply, "Doing your job." That's why your paycheck clears.

Sorry, but that's how it works.

> your management chain is going to decide you aren't picking up enough work in sprint planning

A trivial workaround: "hey team, a month ago I did some research on X, and maybe this is something that could be valuable for us to try". It's mathematically the same, but shhh.

You don't need to lie. It's actually better to reflect for some days on any new research.

It depends. "Let's change to <new JS framework for no reason>" is annoying. But if you do a little more research and reframe the problem to make it simpler, that's just good senior dev work.

Understanding the problem and finding what the business really needs instead of diving in.

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

If planning is very top/heavy and ticket centered, that's a red flag for the organization.

That's actually a great point and a downside to extra work. Maybe the middle ground would be to do extra work for fun and not bring it up, or just finish work early and work on something altogether separate on the side?

Yep. Becoming better and maybe doing better. Sadly often not honored. But I try to keep with this approach :)

This works until you need to find another job.

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.

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.

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.

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.

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.

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!

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

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

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!

All assertions can be derived from a single false assumption.

I think the author's point is "if you have leftover time, do this" not "everyone has leftover time."

> a lot of people who choose to do "extra" are in reality taking time from what would be family/friends/leisure time.

Or they are keeping a buffer in their sprint planning for unknowns, emergencies, etc. Usually this time will get eaten up, but occasionally it won't.

A lot of my time as an entry level engineer at a FAANG was doing "extra" work.

It included:

* Migrating our applications from Java 8 -> Java 11.

* Identifying that our fleet was way over provisioned and then downscaling leading to a huge reduction in infra cost.

* Refactor our infrastructure-as-code package to be more maintainable.

Most of those things were useful but not prioritized. I found them interesting or worthwhile, so I took the initiative and drove them to completion. Most of these tasks were on the timescale of months on the side from my assigned work. I didn't overwork myself to do this -- I very rarely worked more than 8 hours a day.

I found and eliminated a $20k/mo mistake once. It was … stunning. In an instant, I paid for myself, and to very little fanfare. Just poking around trying to understand the high level about where the costs were.

On the more mundane side, rewrote a script from bash to Python. The change didn't really change the script, in that the original is more less doing its job (just… poorly, and wasting a lot of human time on the side), but the output is much more readable, and should quell a lot of confusion from people not grokking exactly what the output of the script is telling them. (You really had to read the bash to understand the output. But the Python can pretty it up, by way of being able to parse & collate… so it should be much more understandable. Also fixes a few bugs from the original…)

I was developing designs in a complex problem domain, and I spent some time prototyping an ontology and inference thing to automate part of the design work. Didn't work out -- my time box circuit-breaker triggered -- but it helped clarify aspects of the problem domain in my head. I would say my "extra" compulsion over decades has enriched my career hugely, for both me and my employers.

Here is one recent example: My project was to write a script to support a mechanical engineer in life testing some buttons that I interfaced with. The script development went faster than I expected, so with my "extra" time I decided to learn how to use a new testing technique on the project.

On the topic of 'looking around for potential improvements/optimizations': I pretty much eliminated my team's several-GB memory spikes we got from time to time. We all knew they were a problem from our dashboards, but no one investigated it, or wrote a ticket for ourselves. I felt curious one day during some downtime @ work, checked logs, debugged locally, and submitted a tiny patch with pictures of the memory savings during a single test run.

Building on the web form example given by the author, there is a lot of extra that one could do: Improve the design, improve user experience, improve performance, format/cleanup the code, add some extra features, add flags to enable alternative behaviour ...