3 ms·
I read it differently, perhaps because I feel so strongly about this idea: do a good job, focus on what's important. If management doesn't appreciate you for
by unoti 16y ago
I read it differently, perhaps because I feel so strongly about this idea: do a good job, focus on what's important. If management doesn't appreciate you for that, then it's a terrible place to work. If you're doing a good job and they aren't appreciating it, then you seriously need to gtfo. If you don't, you will rot.
Over the years as I've looked around me, I've seen a lot of people stagnating in their jobs. Sometimes it's because of lack of effort from the developer, and sometimes it's because of poor management.
But if doing a great job isn't already enough, then maybe the job is a poor fit. The parable in the story touches on both of these issues: trying hard, and the struggle to please management.
A third issue that's perhaps more important: you need to find the work fulfilling for your own reasons. Working exclusively for the praise of your superiors is a good way to be unhappy with your employment in most places. So figure that out, or go to a place where the work matters.
And buyer beware: there are places even in San Francisco where doing good development work will garner you no notice. I just left such a place.
- blntechie 16y agoThink many HNers won't find their life similar to Ashton's. Unfortunately, mine is. At least, the job part is. Honestly, it's not much bad but it looks like it's leading towards the same frustration.
- HeyLaughingBoy 16y agofocus on what's important. If management doesn't appreciate you for that, then it's a terrible place to work Do you mean focus on what's important to you or what's important to management? I agree that if you focus on what's important to the people you work for and they don't appreciate that, then it's a crappy place to work. But what's important to a developer is often completely irrelevant to the business.
- unoti 16y agoThat's a great point. I meant what's important to the company, which hopefully is the same thing as what's important to management. It's funny how thought provoking your question is, though. Because a lot of developers, as you point out, care about far different things for their own reasons. One developer I knew, cared more about everything being 100% as "efficient" as possible before releasing it. She didn't care if things ever got released, really, that didn't matter as much as whether it fit her personal ideas of what's aesthetically ideal. To show you how extreme that was, she spent a week writing a caching layer (in python) using a hashtable + list for a least-recently-used algorithm. When I mentioned she could do this in 2 lines of code talking to memcached, she refused, pointing out how silly it is to talk to an external process with a context switch to look up some data. Who's right and who's wrong? Hard to say. I guess it depends on the context, and what the company is trying to do. I think the answers are different if you're trying to show good, sustainable results for customers without muddying up the code base, versus if you're writing software for lunar rovers.