Hacker News

9 days ago by 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.

8 days ago by 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.

9 days ago by 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.

9 days ago by 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.

8 days ago by 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".

9 days ago by 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.

9 days ago by swiftcoder

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

9 days ago by SavantIdiot

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.

9 days ago by glitchc

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.

9 days ago by ileight2

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

9 days ago by mobjack

A lot of playing politics is just knowing the type of extra work that will get you promoted.

8 days ago by alienthrowaway

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.

8 days ago by brokenmachine

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.

9 days ago by kubanczyk

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

9 days ago by abraae

That will work well .... for a month.

9 days ago by User23

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.

9 days ago by asdfman123

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.

8 days ago by IanSanders

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.

9 days ago by IanCal

That sounds like normal work to me. Identify business value, communicate, prioritise, build.

9 days ago by 908B64B197

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

8 days ago by tonyedgecombe

Yes, if you haven't got at least some autonomy then move on.

9 days ago by rm445

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.

8 days ago by ho_schi

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

9 days ago by Traubenfuchs

Never do more. Never do extra. Always do less.

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.

8 days ago by killtimeatwork

This works until you need to find another job.

9 days ago by vzaliva

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.

9 days ago by dkarl

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.

9 days ago by bsder

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.

9 days ago by indymike

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

9 days ago by aeturnum

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.

9 days ago by dkarl

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.

8 days ago by ornornor

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.

9 days ago by aowen

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.

8 days ago by Zababa

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.

9 days ago by nkssy

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.

9 days ago by dgs_sgd

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

8 days ago by musicale

All assertions can be derived from a single false assumption.

Daily digest email

Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.