Always Do Extra(bennorthrop.com) |
Always Do Extra(bennorthrop.com) |
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.
"Extra" sounds a bit like "gold plating".
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.
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.
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.
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.
All of those nights, it turns out, I did extra.
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've followed that philosophy ever since.
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.
how will these two wacky characters play off each other I wonder!
on edit: added in wacky characters.
I’m honestly not convinced it has much to do with developer longevity though.
People who get ahead build relationships. The slaves stick around to do the extra work.
Competence + relationship > competence + extra work
It's so funny how all the business advice is about how to be a good slave rather than what really gets you ahead.
Don’t. Ever. Give. It. Away. For. Free.
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.
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?
https://elsajohansson.wordpress.com/2016/12/28/your-employer...
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.
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.
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.
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".
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...
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
But you are. Choosing extra is choosing to ignore the prioritised work for something you want to do instead.
Just because the estimate was too low this week doesn't suddenly mean there's no more work.
While I think what they describe as Extra is valuable, I think there are reasonable paths to it:
* Get paid by the project, not the hours. Then the time is yours.
* Get buy-in to spend a reasonable amount of time doing "extra" things.
The latter has the obvious benefit of not only happening when people estimate things wrong.
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.
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!
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.
So no, money first please.
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.
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.
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.
Always doing Extra (and not being appreciated for it) is a great recipe for Burnout.
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.
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.
Understanding the problem and finding what the business really needs instead of diving in.
- 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.
If planning is very top/heavy and ticket centered, that's a red flag for the organization.
Congrats, now you get credit for the extra work and you're a "10x rockstar".
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.
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 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 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'm reminded of the YAGNI ("you aren't gonna need it") principle. Sounds like your coworker could apply it more.
Edit: another good example of Extra would be to build useful tooling for your codebase. It's usually higher-level work.
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!
How's the pay/option package at your current place?
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.
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 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
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".
Edit: Now I'm thinking about what kind of tooling I'd want to make the process seamless.
(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...)
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. :)
A private Git repo where all the work happens, and a public repo where everything is 3 months old, but history rewritten so the dates are up to date?
And a cron job and scripts to automate it all
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.
They always do, especially if you never switch jobs, but there's no need to unsustainably accelerate this process.
Do good work, don't burn out, get paid. Keep things simple.
New university graduates don't, at least I didn't :-)
And they can stay clueless for many years, if they're a bit shielded from office politics by a caring manager
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.
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.
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)