Live data from Hacker News

Always Do Extra

bennorthrop.com

81–90 of 129 posts

Re: Always Do Extra

#82

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.

[deleted]

Re: Always Do Extra

#83
When you do extra, make sure it is recognized by your employer or go freelance and reap the benefits yourself.

Don’t. Ever. Give. It. Away. For. Free.

Re: Always Do Extra

#84
post #6

> 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, an…

All assertions can be derived from a single false assumption.

Re: Always Do Extra

#85
post #74
post #70

Earlier quoted context omitted.

Actually I dislike it intensely. Politics always gives rise to the most mediocre ideas.

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…

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.

Re: Always Do Extra

#86
post #41

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 discove…

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!

Re: Always Do Extra

#87
post #39

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…

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.

Re: Always Do Extra

#88

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 t…

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…)

Re: Always Do Extra

#89
post #16

> In the end, I hope it's clear that I'm not arguing that we neglect our Normal Work. 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 h…

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.

Re: Always Do Extra

#90

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

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