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.
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.
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".
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.
> 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 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, 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.
Everyone knows damn well enough that internal politics can either make this story shine like a diamond, be pushed into a black morass, or everything in between. Internal politics supersedes all best practices in any country, market, or decade
Such a cop out response. "Politics" is interacting with your peers, your superiors, clients, vendors, etc. It's being able to articulate why your ideas are better from technical, organizational, and/or business perspectives. When you have ideas that shine in one of those categories but are absolute shit in the others, or when you have decent ideas but are terrible to work with, it's much easier to just get defensive and say that it's "politics" that made the "mediocre" (but better-suited) ideas rise to the top.
Wow! I think we would all like to come work for that perfect organization where you've found a place. Perhaps I am the only person in the world who has ever heard the phrase "office politics", but, in my experience, as ileight2 says in an earlier comment, internal politics can supersede any other consideration (including money!) in any country, market, organization, and time period.
I've found myself, peers, superiors, etc. to be on bell curves with respect to sharpness, being open to new ideas, articulateness, being able to see through buzzwords and BS, etc. Some people are good in some areas and not quite as good in other areas. Pair a "used car salesman" peer (articulate, not so bright, looking to their own advantage) with a "gullible buyer" superior (not so sharp, can't detect that they're being played) and your "better-suited" ideas that rise to the top truly are mediocre, bad, or outright wrong with respect to whatever characteristic "better-suited" applies. Of course there are examples of good ideas being well-received and acted upon, but don't pretend that only the cream rises to the top or that there are only isolated instances of the dregs rising to the top.
Communicating your ideas well and convincing people you're right are both valuable skills that can be used or abused (which is when they are derided as "politics"). Engineers who do not master these skills are putting a cap to their career growths, if they desire to be anything other than ICs.
I say this as an introvert and as a person who chooses words carefully to reflect my best guess at the truth, which non-engineers commonly mistake for lack of confidence in product/estimate/my ability. Dealing with architects (or even seniors) who can't sell their vision or opinion and/or fail to amicably disagree on technical issues is always a painful experience. It does not have to be that way.
It seems people here mean different things with the word "politics" -- to some, it means ~ manipulation, to others, effective communication?
And then of course people disagree about if it's good or bad or normal?
> Engineers who do not master these skills are putting a cap to their career growths,
Maybe can make sense for an organization to give everyone some practice in communication and presenting ideas -- to give the good ideas better chances (also if the idea person initially wasn't a good communicator)
You don't (usually) get promoted for doing your job - no matter how well you do it. You get promoted when you doing the next rung up, but don't have the title yet. I learnt the hard way.
You're probably doing the wrong kind of "extra", which will just end in you being the only person who can do $CERTAIN_TASK, so you're always the person assigned to do $CERTAIN_TASK and therefore so essential that you can never be promoted to do something else.
> 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'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.
I've had a researcher describe to me how a lot of times they have to submit a grant proposal for what they're already doing, funded by a previous grant. If approved, it will actually be used for the next chunk of research...
(I don't recall why, exactly. Something about how there's a chicken and egg problem, where they wouldn't have enough results to support the grant proposal if they hadn't already been doing the research...)
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. :)
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.
If every suggestion like this came with discussion
- What will it cost
- What problem will it solve
- What advantages will it bring
- What disadvantages will it cause
, then there would be no reason not to bring it up. Maybe I'm just jaded, but when you try to bring up these points, people often (subconsciously?) try to "sell" their suggestion instead.
> 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?
Yes, and the next time a 50-hour task comes up, they'll expect you to do it by tomorrow.
The problem with faking your way into being a 10x rockstar is that expectations grow faster than compensation. The other problem is that if you can't sustain the pace, you're going to burn out and your life will be utter crap.
I'm pretty sure you're supposed to catapult into doing training and speaking stuff, and "leadership" roles that have you writing blog posts and attending meetings all day while taking credit for what your team is doing, after faking your way to a "10x" reputation.
No. Sometimes something just does work out faster, so explain that. Spend a little longer anyway as if something is vastly faster than expectations then perhaps something's been missed. Then when still presenting it faster, explain that it was faster than planned and shouldn't be taken for granted.
Really interesting article about enabling longevity and success as a software developer, but it matches my view on all kinds of skilled work: whatever your employment arrangement, treat yourself as an old-fashioned professional.
Like a doctor or barrister, more tied to your profession than to one job. You need to be effective in your role, build your reputation by demonstrating your skills are beyond the bare minimum, and continually develop yourself as you go along. Ideally you get lots of win-wins: your 'extra' is a win for the company in the long run, and you come out of it a little wiser, and over time you're more effective due to the effects of past 'extra'. The benefits of these win-wins can be pretty intangible, but they do build up over time.
Still homeworking? I recommend playing the piano for the rest of the week after you finished your properly overestimated tickets. Any other instrument will do. You can also cook one new dish a day, work out or learn any other new hobby! Feeling uninspired? Just clean, do a spa day or watch tv.
Trapped at work? Read a book! You could also try audio books if reading isn‘t your thing.
It‘s important to always overestimate tasks and blow them out of proportion. Have careful conversations with team members to encourage them to overestimate and teach them this skill. Keep 10x rockstar developers out of the team, if at all possible. Be an inspiring leader to help manage the worklife balance of your teammates!
Never forget to prepare something to say in the standup for every day. Do more work at the beginning of the week.
You will pick up new skills this way and have lots of things to talk about.
Great article! My feelings exactly. One thing to add: doing "extra" sometimes requires you to be little irresponsible. In the example in the article, many responsible programmers will opt to do "More" (3rd screen) instead of "Extra" because they know the project is past deadline and company really needs it. However this kind of thinking is is a trap. There is always an incentive from a company to do "more". One should learn to ignore it to do "extra." instead.
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.
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.
> 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.
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.
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.
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.
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.
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!
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.
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!
Glad about the explicit exploration of "extra" versus "more".
Extra to me is often about your development. Learn now to do it next time either better/faster/smoother etc etc. I'll agree with that idea.
The issue of extra is often then who pays for it. That can really make you enemies. People like free. Also, being over eager about improvements can put you on people's radar as a threat depending on how dysfunctional either they or the organization are.
As a contractor the extra means you can get the same output faster or with less effort because you improved your process. Or you can charge more.
Now differentiate this from "more". If you do more you over deliver. Instead of two deliverabkes, you do three. I'm ok with that if you get paid for it. It might even get you promoted if someone notices. Be careful that when it doesn't help it might actually hurt you later. Expectations from not-so-good bosses can be subject to inflation when they see you provide more than they pay for.
There are pros and cons to both. Its not an either/or situation either. You can use both to advantage.
> Assume there's a reasonable amount of work you need to do to fulfill the base expectations for your job (i.e. your Normal Work) and then there's a little time left over.
In my experience "a little time left over" is usually not enough time to bring meaningful "extra" work to the table. If I'm going to bring in something new and useful, and also be able to sell it to my team, then it's hours of research, testing, and convincing.
i agree that going off-roads from the main task is useful but i disagree with the way the author is suggesting to do it.
> Assume there's a reasonable amount of work you need to do to fulfill the base expectations for your job (i.e. your Normal Work) and then there's a little time left over. (I know some may argue this "left-over time" thing, but just go with me)
this assumption fails at a lot of companies, especially smaller startups. with tight sprints and PMs breathing down your necks to get every ounce of work out, there is no "left-over" time. a lot of people who choose to do "extra" are in reality taking time from what would be family/friends/leisure time. i'd take being a mediocre dev than sacrificing my personal time.
i have found things at FANG company to be different tho- they don't use sprints and as such I can set my expectations so that I can have my "extra time" during company time.
Fantastic article. As a UI designer, I feel like the little bit of "Extra" work that I've done in my career has paid off extremely well.
Of course, you need a manager who understands the intent behind your Extra work is that it is mutually beneficial and that you strike more than you miss when doing that Extra work. If these fall into place, you'll be treated with more respect and will be given more autonomy which further encourages you to do what is right both for yourself and the company you work for.
That's been my experience in my relatively young career (7-8 years). This article sums up this concept really well.
Does anybody have good examples of 'extra' work they've done? I agree with the author's assertion that doing extra benefits one a lot more than baseline or more work. It's essentially a way to inject creativity and studying into one's normal work, as opposed to just flat-out working on a different project or straight up studying documentation. That comes with the benefit of being able to show it off in various ways that studying or a side project don't offer (value add, taking ownership, etc).
However one thing that I find challenging about the idea is what to do. I know that kind of comes down to asking "how to be creative", but if anyone has concrete examples of the kind of 'extra' work the author describes, that would be helpful as a model to use.
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.
So you did your regular work and in your extra time during normal work hours, you also thought of and executed on these ideas? Did you ever seek approval or just go for it? By the time I proposed ideas like this in a PR or something, I imagine my manager would question why I'm spending so much time on this kind of thing
Exactly! I worked on things that had value for my team and was interesting to me.
I bounced ideas around with coworkers, but I never asked for approval. As long as you’re doing your assigned work I don’t think your manager should care. This will depend on your company/manager of course; I was lucky to have ~3 managers during my tenure who were hands off
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…)
Awesome job. Makes total sense how switching to Python would improve things. What was your approach to understanding what the costs were, like just looking at memory and space cost, or its cost when running on the actual infrastructure?
The cost thing was just looking at the bill. I've worked at some companies where engineering didn't even have access to the AWS bill, for example, which is rather unfortunate, since engineering is where the knowledge of "wow, this pie slice shouldn't exist" is. (I do think finance could? should? have noticed that bill, since I in part noticed it b/c the monthly total was too high. But I might have been looking at a more broken-out number than the actual, final total there were some other things that might have gotten mixed in that would have dulled the signal enough to make it plausibly missable.
But after seeing the number, it was a pretty quick task to break it out into various areas over time (like total VM$/time, total storage$/time), find the category that grew, and repeat until the offender was found.
The script thing was mostly about time. Bash's output was only so intelligible (it was basically |grep|awk|grep sort of thing) and engineers would get confused, ask questions, and it soaked up enough time to make me say "let's rewrite this so I never have to answer these questions again".
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 ...
This one is a good, understandable example, though I wonder how I would pitch the value add for these things. Usually my team is so busy I imagine my manager telling me to focus on other work first
Interesting article. Autonomy (or at least a smattering of it) is definitely key to staying engaged at work.
But I would say that actually those types of research that he mentions are often pretty important aspects of the engineering. And even further, initiatives for new technical approaches or even new features can also be quite important if the project is going to stay up to date and really tackle core technical or business challenges in a robust way.
The degree that autonomy seems "extra" rather than normal in the job may be a bad sign.
So, learn on the job. Why we do not have the same learning time that doctors. Time to learn, time to go to conferences, time to share knowledge with colleagues.
Study at home makes no sense if society expects people to have children and educate them, or just to not burn out and leave the field for good.
Can't that extra be something unrelated to your current project?
I like how Google lets employees use 20% percent of their time to work on other subjects that their current projects. More companies should do this. The value is huge: less bored developers, less burnt out developers, innovation and development of potential very useful features for the company.
This is how I do it. I used to try to put my extra into our product directly, but eventually learned how disruptive this pace was for the team.
Now, I spend maybe 1 day a week working on a personal side project where I can get all that energy out of my system. Every 3 months or so, I will find a very useful nuget in the side repo that I can gently introduce to our product repo.
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 idea is not to do overtime. The idea is to use some of the slack you have because you finish your normal work early to consider process/architectural improvements or similar. Some people here consider it so obvious, that they even say it is part of your normal work. Well, I would say this mindset is much better than having worker bees who don't ever question anything and you end up with large inefficiencies because those who would maybe be empowered to define such work (like managers) don't have enough detail insights to actually do this.
I get the idea. I am not sure about the practical implications outside the individual advancements.
I have somewhat anecdotal evidence that the best production environment is composed of different people, in some part of your production you need "worker bees", and in architectural and research processes you need people with natural curiosity and experimental nature.
Even the author has some doubts of his argument in production.
>Shirking our Normal Work in favor of Extra might be more interesting, but it makes us shitty teammates at best, and unethical at worst.
> The second rule of Extra is that it must be aligned with your Normal Work.
Yeah advice from a different old programmer: do stuff that isn't aligned with your Normal Work, and restrict how much you're working on Normal Work to the point you're not constantly burned out and have no ability to do other stuff.
In my opinion, doing "extra" as described here is precisely how one can grow into the maligned 10x developer. I promise no one starts out with that kind of mastery.
> Extra is finishing those two screens, but then researching a new library for form validation that might reduce the boilerplate code. Or it's learning ways to protect against common security vulnerabilities from data entry.
How about making sure your code doesn't "work by coincide". Ensuring you don't have any dead code, etc. I recently cleaned up a bit of code by straight up just deleting 80% of the lines. It still worked, it still did essentially the same thing. It wasn't a refactor, just deleting lines. 80% of the code before was just leftovers from someone's experimenting to get it to work, as soon as it appeared to work it was, commit, force push, go home (I'm kidding about the force push, probably). That's not good enough.
So I agree with the article, once it works, you're half done.
This is absolutely valuable on small teams and I repeatedly have seen people on engineering and product do extra (not only on own team, but helping others) and there is this terrific positive environment every time we interacted with cross-domain teams. Overall a win.
There is _always_ more grunt work to be done in our field. The employer would be happy to let you churn out solutions to tickets forever, but this only serves the company, not you.
Doing Extra is acknowledging this and trying to think outside the box for the benefit of both parties.
Also, your employer probably already has someone doing good quality Extra work (to move the company forward in the long term), so it's not critical that you do Extra work. But if you find something like that rewarding you can start doing it and kudos (in several forms) should follow.
I also think Extra is very strongly dependent on your area of control. If you only have control over a very small segment, then there might not be much room for interesting Extra. But if you have control over some high-level processes, then that's where the interesting solutions can really make a difference.
It's not about taking on grunt work, just because you finished some assigned tasks quicker than the person (/team) who assigned them thought it would take doesn't mean the next most important things are grunt work.
If it's beneficial for the company (and I agree that this kind of experimental work is) then make it part of the tasks. Don't only do it when your estimates are wrong!
Maybe that kind of work is beneficial only if it's done by people who find it interesting enough and thus do it on their own accord? I know a bunch of people who don't like this kind of exploration so including this in their task would probably make them start looking for easier tickets/jobs.
Not unless I'm getting paid or recognised in some other way for going extra mile.
More often than not no one (bug some rare customer probably) gives a damn about you going extra mile. Often it is actually punished, not directly but I've had plenty of examples when people instead of doing extra ventured into doing some fun shit for other teams and uh-oh, cross-team impact, here's your promotion while your actual team is struggling to get right the boring but actually money bringing stuff.
:) There will be recognition if you perform tasks that continually uplevels your team. There is only so many buttons one can push in a day (doing more). What the author calls "Extra" is often called "Glue" work (think improving test coverage or isolation, creating a bank of interview questions, improving onboarding documents).
If you ask for "money first", response will often be "IDK, we're not too sure about that". If you improve the organization, there will be money & promotions. There will be a gap in this reward.
Somehow there’s no gap when people are hired for this positions externally and “money first” doctrine applies. I’m not going to spend my personal time and life on saving few bucks on hiring for some corp. If it is easier to change my job for a promotion, I’ll do that.
If you working as a consultant you really need to be careful about doing to much extra work. The customer normally pay for your time. The extra time could end up being something the customer refuse to pay for. In that case your time is better spend on other customers.
More annoying some clients are just weird. We did some client work, and we did what the client viewed as extra work. The project involved some small amount of Ansible to written. We greated a few roles and playbooks, tagged up everything as we normally would.. and the client exploded. Every tag would need to be documented, what did, how to use it, which tags could be used togther and so one. We ended up just ripping out all tags. Something that was a little extra work, but a nice convinience was a major problem to the customer.
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.
> Doing More would be completing those two screens and then taking on a third screen that's just like it. Yes, this would help move the project along faster and make your manager happy, and that's great, but in the long-run, More doesn't give you much.
Always doing Extra (and not being appreciated for it) is a great recipe for Burnout.
Interesting POV. I've been doing "more" as described by the article, and you're right that it's not super rewarding. I like when the team acknowledges the extra points I knock out, but that's a very shallow and temporary feeling. I'll explore doing "extra" for the next few weeks.
I gotta wonder how long these people's backlog is.
I do the thing until it is good enough (which sometimes is less done than initially requested) and then move on to another thing from the pile if I have time. Or I will answer support questions, or review pending pull requests.
I completely disagree - do enough, or failing that, nothing. That is enough to solve the well-defined problems.
Giving extra to your employer for the same money is a recipe for exploitation. Additionally, “extra” tasks are less defined and therefore more likely to be wasted effort.
This comment does not make sense as a rebuttal to the article.
The author is arguing that you should use spare time you have after doing "enough" on things that enrich, educate, and grow yourself instead of simply doing more of your "normal" work. They state very clearly that they think you should not do additional work items that provide clear value to the business. They are saying you should give extra to yourself, not your employer.
While ideal and even natural, I often find that "normal work" usually comes in such fits and starts that it typically make this approach difficult or even impossible.
The most recent time when I had plenty of time and few "normal" stories on my hands there was no normal work to align the extra to. This wasn't as much fun as I thought it'd be. It led to some rather out there "extra" work (from the whole team) that ended up being rather pointless.
There have been a few exceptions where I had really good product managers that ensured a steady work stream that made this possible. Indeed, I found that if the worksteam was steady, it seemed like the obvious thing to do.
Good message, but not hot on the phrasing. Should've said "always try finding better ways of doing things", where 'better' means less time, less future maintenance, more aligned with overall business goals, etc.
I started developing professionally on airgapped networks. At night, I was searching stackoverflow for the ideas I had, best practices of what I did that day, how to do things securely, etc. During the day, I cannot access internet because there was just one workstation with internet connection for about 20 devs, DBAs, sysadmins, etc.
And also you cannot copy-paste, so you needed to optimize what you do. Otherwise, you have to write down the exception you had you don't know, then wait for your turn to use the workstation -add log on ceremony with smart cards, etc.
I learned this decades ago from one of the best IT consultants in the city. I was interning with him, and he told me that for every project he does "one new thing". Typically he tries a new product, a new approach, or just picks up a skill like a specific scripting language.
His thinking is that there's always padding in these projects, so may as well fill the spare time with something that will help him grow. Two new things is too many unknowns and could derail the project, but one new thing is "just right".
I like to think that I do this; every time I touch some existing code, I try to do a round of polish first before getting to the brunt of the work. It's not much, and it won't advance my career much, but it gives me that hit of gratification that I need and that I don't get from adding another form / page / database table / whichever.
>And it's with this decision that every reasonably happy, veteran developer I know distinguishes themselves. They all choose Extra.
Selection without causality can explain this. Turns out people who survive either have personality or environment that enable them to feel the Extra work is worth it. Where I'm at, it certainly doesn't.
Sixteen years in and I agree with the definition of extra but I do that in the bracket of normal work. As in I do the ‘extra’ stuff and take time out of my working day to do it.
I’m honestly not convinced it has much to do with developer longevity though.
I've been stuck in trying to do just the tasks planned. Picking up more when there is spare time. Trying to focus on only billable tasks. I stopped learning and burnt out.
> It's so funny how all the business advice is about how to be a good slave rather than what really gets you ahead.
This is almost literally the opposite of what the article is advocating.
The author is suggesting that should you complete the work required of you then you should spend any spare time you might have on things that benefit _you_ rather than necessarily benefiting your employer. The author spends the first half of the article explicitly distinguishing this from doing additional, unrequested work that contributes obvious business value. The caveats the author provides are to encourage people to do this in a way that isn't going to get them into trouble, pretty much.
Relationship building for engineers nearly always happens outside of the context of the actual work, so I don't think that's particularly relevant.
> Wrong. Business is about relationships. Be competent and do what is minimally required.
Wow. this is the worst advice I've ever read on HN. As an owner, I seek out employees that are good at politics and poor workers and help them find a job at another company (ESPECIALLY COMPETITORS). A lot of times, they even think they are getting a promotion when they leave.
> The slaves stick around to do the extra work.
This is the problem. "Extra" does not mean "extra work". It means go beyond. Solve an extra problem, write that document, squash an unexpected bug or two, organize a language meetup group... something outside the necessary.
> Competence + relationship > competence + extra work
Competence is a low bar that nearly every adult professional meets. Be better than competent is what the extra is all about. Also, building relationships isn't that hard. I can't tell you the number of times that I see people who are bitter about not getting promoted say no thanks to their manager when approached with, do you want to grab lunch?
What about competence + relationship + hard work? Establishing relationships can be a part of work, and also hard work can be relationship building with a boss, who can then promote you... However, I share your aversion to being "a slave" and I also don't like to work for other people. But the only solution seems to be to work for yourself, which requires hard work just to survive. I thus feel like to satisfy the requirement of "no hard work" while working for someone else (because working for yourself is hard), requires the seeking of a position which is highly political and not really outcome dependent (otherwise your soon to be boss will have more incentive to filter you out), which sounds like the formula for some kind of bureaucratic cancerous cyst inside of a company, tbh. Which is something you would ideally not want to be a part of.
This is one of those things that everyone knows is true, but no one can acknowledge it openly. Without vested interest it is simply natural to put one's interest ahead of the company one works for.
In fact, doing extra, or normalizing extra can even make coworkers look bad.
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.