Always Do Extra
81–90 of 129 posts
Re: Always Do Extra
#82Sixteen 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.
Re: Always Do Extra
#83Don’t. Ever. Give. It. Away. For. Free.
Re: Always Do Extra
#84> 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…
Re: Always Do Extra
#85Earlier 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…
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
#86Oh, 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…
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
#87Not 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…
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
#88Does 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…
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> 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…
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.