I totally agree that it's about love of your co-worker, not the work.
The work is inane most of the time. Is your company's code complicated and full of weird curlicues because edge cases from poor planning and requirements that change on the fly 'disrupted' the original design? Do you wish you could rewrite it all?
Because of human nature, and entropy all code outside of personal pet projects devolves into a big ball of mud.[1]
How easy is it to love your work now?
This reminds me of the novel Catch-22. For me the core message of that book[2], was that the only solid thing to believe in was this:
You kept flying missions not because they made sense, or helped win the war, or for the commanders, or for the love of flying, but to help your friends. Because if you didn't fly the mission, some other poor sap would have to risk _his_ life fly it in your place.
Now as programmers in the work world, we don't risk our _lives_[3] but it's a similar thing. If you do a poor job on your bit some other guy is going to have a bad day.
Want some advice from someone who's been doing this for a long time? Forget
about disrupting entire industries and about 'changing the world' just write good code so the other guys can depend on it. This is how you change the world, one task at a time.
[2] War novel about enlisted men caught in a dysfunctional air-force, run by incompetent, if not outright insane commanders who demanded more and more dangerous missions be completed.
[3] Or do we? We risk our lives in small quanta by frittering it away on stupid inane stressful tasks. Do you wish you could be at home in the backyard flipping steaks on the BBQ instead of fighting that fire in production, again? We risk parts of our lives every day this way.
But the military has compulsory service. You can't quit if your general is making terrible choices.
> Because if you didn't fly the mission, some other poor sap would have to risk _his_ life fly it in your place.
This isn't true for development. If your coworkers are pouring into a product with severe defects in the technology or business plan, the best thing to do is start that conversation, not help them waste their effort.
At the end of the day, if your leaders are making bad choices, talk about it and be ready to find a boss or organization you're excited to work for.
>If your coworkers are pouring into a product with severe defects in the technology or business plan, the best thing to do is start that conversation, not help them waste their effort.
I agree, and in that case 'the work' becomes exactly what you described. I never intended to imply that 'the work' always consisted of programming.
Also I'd say that flaws in the business plan are more important to address than flaws in the code. Shitty code has conquered the world many times over, I don't know if I've ever seen an example of good code doing the same. (see below)
>At the end of the day, if your leaders are making bad choices, talk about it and be ready to find a boss or organization you're excited to work for.
Except they all make bad choices, compared to the ideal code we imagined our future selves would be writing. See my comments on the big ball of mud. In the end the centre cannot hold, mere anarchy will be loosed upon the world[1], and all that code will devolve into a big ball of mud anyway. If the business plan is good the CxOs and sales guys will be happy, though.
So in my opinion, it can be better to stay at a company that is good enough, with colleagues and bosses that you know, instead of idealistically seeking some programmer heaven that doesn't exist filled with colleagues and bosses that you don't know.
The work is inane most of the time. Is your company's code complicated and full of weird curlicues because edge cases from poor planning and requirements that change on the fly 'disrupted' the original design? Do you wish you could rewrite it all?
Because of human nature, and entropy all code outside of personal pet projects devolves into a big ball of mud.[1]
How easy is it to love your work now?
This reminds me of the novel Catch-22. For me the core message of that book[2], was that the only solid thing to believe in was this:
You kept flying missions not because they made sense, or helped win the war, or for the commanders, or for the love of flying, but to help your friends. Because if you didn't fly the mission, some other poor sap would have to risk _his_ life fly it in your place.
Now as programmers in the work world, we don't risk our _lives_[3] but it's a similar thing. If you do a poor job on your bit some other guy is going to have a bad day.
Want some advice from someone who's been doing this for a long time? Forget about disrupting entire industries and about 'changing the world' just write good code so the other guys can depend on it. This is how you change the world, one task at a time.
[1] http://www.laputan.org/mud/
[2] War novel about enlisted men caught in a dysfunctional air-force, run by incompetent, if not outright insane commanders who demanded more and more dangerous missions be completed.
[3] Or do we? We risk our lives in small quanta by frittering it away on stupid inane stressful tasks. Do you wish you could be at home in the backyard flipping steaks on the BBQ instead of fighting that fire in production, again? We risk parts of our lives every day this way.