4 ms·

Of course the day job isn't always fun. That's why it's a job and that's what we get paid for. But: I f'ing love my job as a programmer. There is nothing in th

by pilif 13y ago

Of course the day job isn't always fun. That's why it's a job and that's what we get paid for. But: I f'ing love my job as a programmer. There is nothing in this world that I'd rather do. There's nothing that constantly fills me with as much joy as programming does. I admit that I might be a bit lucky here, having founded the company I'm working for; that allows me to pick my battles and find a good balance between stuff that's pure joy and stuff that's just a job. I do however look out for everybody here who likes solving the interesting problems as much as I do - we try to keep the interesting problems evenly distributed between us. The thing is: Many of the crappy tasks can still be made interesting: Form a challenge. Fix something related that has been bugging you constantly. Try to implement the crappy feature without performance regressions. Try to implement it in the cleanest way possible. Try to make your future self proud. If it goes beyond changing the working in an email for the 100st time, I'm sure there is something in there that can make your task bearable or even enjoyable. At least it is for me.

AznHisoka 13y ago
Not to say your opinion doesn't count but theres a huge difference between being the founder of your own company and following orders from a pointy haired boss. True being a boss is not all roses but your problems shift to a higher order, such as how can I build something customers would love... Versus how can I fix this trivial bug because my boss told me to?
iSnow 13y ago
I think, as a founder you are missing the point that 99 out of 100 times you are told - explicitly or by work schedule "do not do it in an interesting, performant or elegant way, just get it working somehow and move on"
- pilif 13y ago
  Oh I know (I also said so in my comment). And that's why I consciously try to distribute the interesting work between my coworkers and I. That way everybody gets a nice mix between "job" and "fun". Does that mean that sometimes I have to do crap? Yes. Does that mean that everybody gets to have fun at times? Yes. If I can help it at all, I will not be the person responsible for somebody to write the rant that OP has posted.
  - Sarien 13y ago
    Very well put, a nice mix between "job" and "fun". Except that most employers want their employees to do the "job" part of everything and do any "fun" parts in their spare time.
    - mooreds 13y ago
      I think that good employers want their employees to enjoy their jobs (and hence, have some 'fun'). I manage a few folks, and want them to enjoy their work. Of course, it's not all sunshine and puppies--there's grunt work that just has to get done, and everyone takes their share. Crappy employers of programmers just want to exploit employees, just like crappy employers of other kinds of workers.
    - victorf 13y ago
      That's a shitty employer; 1. it's sadistic to require programmers not enjoy their work 2. if you've got a bunch of bored programmers you're going to lose your top-tier men and women to more interesting jobs.
- AlisdairSH 13y ago
  Isn't that a challenge in and of itself? The majority of us are solving business problems, not technological ones. If I can deliver something, even if not the most interesting or elegant, that gives the sales/marketing people giant, shit-eating grins, well, kudos to me. Usually, that means I'll be given time to go back and make enhancements, add functionality, or placed at the top of the list for the next cool project.
- jasonlotito 13y ago
  I've never been told that. I've been told to get something done. How I achieve that has never been an issue. Interesting, performant, or elegant does not mean it has to be slow. That's part of the challenge. Meeting the demands of the business while meeting the demands of a professional.
  - resu_nimda 13y ago
    In my experience, virtually every coding task takes longer to do "the best way" than the quickest or easiest way. Many times it takes much longer. Either you are a savant-like exception to this rule, or your velocity is (significantly) lower than it could be. Don't get me wrong, I push for doing things the right way whenever I can, but acting like you can have it all with no compromises seems silly.
    - collyw 13y ago
      Depend on whether you are looking at the immediate time scale, (when "the best way" takes longer), or over the longer term, where it is often a lot better to sped the time up front, and have a good solution, rather than a quick hack.
  - iSnow 13y ago
    >How I achieve that has never been an issue. Lucky you, I have been there too. But at my current position, trying to use more modern technologies (Angular.js for example instead of a 15-year old stack without clean separation between front-and backend) to be more efficient is met with stares. And I venture to say this happens very often in a lot of shops. At least outside of California.
- noptic 13y ago
  "um yeah nice, just ... remove the comments. And whats that tool? You can use Emacs for that! And we already have a mechanism for that just put a sub in <that> namespace and name it on_db_<whatever>_insert_trigger!" Then I go home and write pure OO coffescript/C#. The company is great, but we have very different views on how software should be desigened.
- EdwardDiego 13y ago
  > that 99 out of 100 times you are told - explicitly or by work schedule "do not do it in an interesting, performant or elegant way, just get it working somehow and move on" Sure, we're in businesses (well, most of us), and there's little room for gilding the lilly or perfectionists who can't deliver. That said, I've always found that elegant code is easier to maintain, thus reducing technical debt. If your employer doesn't want to reduce technical debt, you're either working for a start-up that's in a mad rush to 1.0, or you're working for someone who doesn't understand or care about the interest you pay on technical debt, and it may be time to move on.
- collyw 13y ago
  my (less experienced) team leader is always going for the "just get it working solution". I often fight back to take the time to produce something more elegant, knowing that in two months time, my solution will not need fixing a second time.
smoyer 13y ago
I agree whole-heartedly ... There are very few days when I dread what I have to work on, and you can always find something to improve.
hipsters_unite 13y ago
Totally agree, I've done other jobs that are so many orders of magnitude worse than programming that it doesn't bear thinking about. For all its flaws, coding rocks as a career.
sirmarksalot 13y ago
The "challenge" strategy can be intensely satisfying, but can also be very frustrating if that challenge is not shared by everyone on your team. I've approached problems with goals like trying to do everything in a declarative functional style, and not passing nulls to avoid having to check for null. It's worked great, until we hand the code off to somebody else, with a new requirement, and that person breaks all the rules not because it's a particularly hard problem to solve, but just because they don't care. It's an issue I'm currently working through right now, and I'm not sure if it's something to write a style guide/manifesto for, or if there's a better way to enforce it, or if it's just not a battle I should be fighting when dealing with an outside vendor.

by pilif 13y ago

AznHisoka 13y ago

Not to say your opinion doesn't count but theres a huge difference between being the founder of your own company and following orders from a pointy haired boss. True being a boss is not all roses but your problems shift to a higher order, such as how can I build something customers would love... Versus how can I fix this trivial bug because my boss told me to?

iSnow 13y ago

I think, as a founder you are missing the point that 99 out of 100 times you are told - explicitly or by work schedule "do not do it in an interesting, performant or elegant way, just get it working somehow and move on"

pilif 13y ago
Oh I know (I also said so in my comment). And that's why I consciously try to distribute the interesting work between my coworkers and I. That way everybody gets a nice mix between "job" and "fun". Does that mean that sometimes I have to do crap? Yes. Does that mean that everybody gets to have fun at times? Yes. If I can help it at all, I will not be the person responsible for somebody to write the rant that OP has posted.
- Sarien 13y ago
  Very well put, a nice mix between "job" and "fun". Except that most employers want their employees to do the "job" part of everything and do any "fun" parts in their spare time.
  - mooreds 13y ago
    I think that good employers want their employees to enjoy their jobs (and hence, have some 'fun'). I manage a few folks, and want them to enjoy their work. Of course, it's not all sunshine and puppies--there's grunt work that just has to get done, and everyone takes their share. Crappy employers of programmers just want to exploit employees, just like crappy employers of other kinds of workers.
  - victorf 13y ago
    That's a shitty employer; 1. it's sadistic to require programmers not enjoy their work 2. if you've got a bunch of bored programmers you're going to lose your top-tier men and women to more interesting jobs.
AlisdairSH 13y ago
Isn't that a challenge in and of itself? The majority of us are solving business problems, not technological ones. If I can deliver something, even if not the most interesting or elegant, that gives the sales/marketing people giant, shit-eating grins, well, kudos to me. Usually, that means I'll be given time to go back and make enhancements, add functionality, or placed at the top of the list for the next cool project.
jasonlotito 13y ago
I've never been told that. I've been told to get something done. How I achieve that has never been an issue. Interesting, performant, or elegant does not mean it has to be slow. That's part of the challenge. Meeting the demands of the business while meeting the demands of a professional.
- resu_nimda 13y ago
  In my experience, virtually every coding task takes longer to do "the best way" than the quickest or easiest way. Many times it takes much longer. Either you are a savant-like exception to this rule, or your velocity is (significantly) lower than it could be. Don't get me wrong, I push for doing things the right way whenever I can, but acting like you can have it all with no compromises seems silly.
  - collyw 13y ago
    Depend on whether you are looking at the immediate time scale, (when "the best way" takes longer), or over the longer term, where it is often a lot better to sped the time up front, and have a good solution, rather than a quick hack.
- iSnow 13y ago
  >How I achieve that has never been an issue. Lucky you, I have been there too. But at my current position, trying to use more modern technologies (Angular.js for example instead of a 15-year old stack without clean separation between front-and backend) to be more efficient is met with stares. And I venture to say this happens very often in a lot of shops. At least outside of California.
noptic 13y ago
"um yeah nice, just ... remove the comments. And whats that tool? You can use Emacs for that! And we already have a mechanism for that just put a sub in <that> namespace and name it on_db_<whatever>_insert_trigger!" Then I go home and write pure OO coffescript/C#. The company is great, but we have very different views on how software should be desigened.
EdwardDiego 13y ago
> that 99 out of 100 times you are told - explicitly or by work schedule "do not do it in an interesting, performant or elegant way, just get it working somehow and move on" Sure, we're in businesses (well, most of us), and there's little room for gilding the lilly or perfectionists who can't deliver. That said, I've always found that elegant code is easier to maintain, thus reducing technical debt. If your employer doesn't want to reduce technical debt, you're either working for a start-up that's in a mad rush to 1.0, or you're working for someone who doesn't understand or care about the interest you pay on technical debt, and it may be time to move on.
collyw 13y ago
my (less experienced) team leader is always going for the "just get it working solution". I often fight back to take the time to produce something more elegant, knowing that in two months time, my solution will not need fixing a second time.

smoyer 13y ago

I agree whole-heartedly ... There are very few days when I dread what I have to work on, and you can always find something to improve.

hipsters_unite 13y ago

Totally agree, I've done other jobs that are so many orders of magnitude worse than programming that it doesn't bear thinking about. For all its flaws, coding rocks as a career.

sirmarksalot 13y ago

The "challenge" strategy can be intensely satisfying, but can also be very frustrating if that challenge is not shared by everyone on your team. I've approached problems with goals like trying to do everything in a declarative functional style, and not passing nulls to avoid having to check for null. It's worked great, until we hand the code off to somebody else, with a new requirement, and that person breaks all the rules not because it's a particularly hard problem to solve, but just because they don't care. It's an issue I'm currently working through right now, and I'm not sure if it's something to write a style guide/manifesto for, or if there's a better way to enforce it, or if it's just not a battle I should be fighting when dealing with an outside vendor.