Always Do Extra

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

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

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.

Sharing my limited experience. In any way or form I don't imply that my point of view is right. Producing software is complex process that requires constant adjustment and change.

I have successfully run my company (middle level web-shop) and delivered results for more than 16 years. In my PM practice I never required my engineers to do "extra". In my view this is not productive approach at all.

Creating the adequate communication channels and production processes with transparency delivers results. Defining clear rules of engagement for the teams in research, prototype and production stages removes the "need" of "extra" work or overtime.

I understand the thesis of the article, but respectfully disagree with the author. Doing extra work for yourself as an investment in being better is definitely a good thing.

But doing this in production will create misalignment and frustration within the team, and the overall net effect will not be higher quality.

I think the observation is great but the implication of causality is the wrong way around..

People who get enjoyment from their programming job will like to Do Extra as they probably also get enjoyment from new tech, extending themselves, etc etc.

People who don't get enjoyment from their programming job won't get enjoyment from Doing Extra, so they won't naturally do it.

Telling one of the latter to Do Extra probably won't turn them into someone who gets enjoyment from a programming job.