[pedalpete]

I feel like the people who do "extra", never feel like they're doing extra, they feel like that is part of the job.

The example of "creating two screens", you make the screens, and then look at them and think...is this the best I can do? Is there a better way to protect the security? Is there a way I can reduce the boilerplate? Can I refine this so it's easier for somebody else to maintain later?

That's the job, as far as I'm concerned. It's the same in many other professions.

I like Ryan Holidays perspective on this in Perennial Seller. As a writer, you're not done when you write the chapter. That's the start, now you've got editing, and re-writes, promotion, sales...that's the work.

[Cthulhu_]

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.

[gopalv]

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

[oneepic]

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.

[makeitdouble]

The catch is, depending on your environment that's not the extra distinguishing you, it's the baseline.

I've seen it first hand in some startups where you have to manage yourself, and you'll be the only one to give yourself the time to look back at your work, and make sure you're growing and making better things.

I also hope that the "extra" is done within standard working hours, which is an other argument to just have it set as "part of the job".

[lmeyerov]

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.