Love thy coworker; thy work, not necessarily | Hacker News Reader

Love thy coworker; thy work, not necessarily

yosefk.com

86 pointsluu50 comments

This comment from "Jack" says it all:

> Well, you can also be motivated by doing a good job regardless of what that actually entails. For example, I'm a very good programmer. Programming has become boring because there is no challenge anymore. But I do enjoy producing very high quality output and being better than almost everybody else. So I don't care what I program or who uses it but I want it to be the best possible engineering solution.

No, you're not a good programmer because there's no challenge any more. You're a bad programmer because you've lost sight of the context of your work. If you're bored, it's because you're solving easy problems which have already been solved, probably for some turd-polishing startup that calls putting a Web 2.0 interface on top of a rewritten old solution "disruption". Someone will pay you because the ad business can sell any crap, but you're not producing value; you're just producing stuff that can be sold.

If you were really "better than almost everybody else" you'd be hired to work on hard problems that even someone actually better than almost everybody else would find challenging. There is no shortage of difficult problems that people need solved. And incidentally, real ability gives you options to choose what problems you want to solve, so you can pick a problem you can find at least a little passion about.

Sure, you can treat your startup as a country club where the members are more important than what you're actually doing; that's a lifestyle some people enjoy. But let's not entertain the delusion of grandeur where that makes you a good programmer: that just makes you a member of a country club.

Being altruistic and/or ambitious is not a prerequisite to being technically better than other people, gaining skills can just be done for personal pleasure.

My strengthsFinder assessment lists Life Long Learner as one of my top 5 strengths. And that is so true. I love learning new things to the point that if I'm not careful it can be dysfunctional. It is not so much about learning something deep as it is about learning that something is possible and whether it is easy or hard.

Being that my job is to develop and manager a small team of developers I can easily satisfy my quest to learn. I just have to be careful to not then burden my team with new technology for the sake of technology since whatever tools and tech we use has to be supported by a very small team long after I am gone.

On the plus side if I do this well then I uncover technology or tools once in awhile that help the team achieve our goals faster, better, cheaper.

Yup, I think is very common, I'm in a similar position and feel the same way. Partly it feels like a game; filling in holes in knowledge is like locating pieces that fill gaps in a jigsaw. And partly it feels like a scrabble up a hill - the more you learn, the more you realise how little you know, so you try to grab more and more knowledge.

And it does lead very often to bad programming, I appreciate the GP point - reinventing wheels, NIH syndrome, overuse of clever techniques etc., but that's not necessarily the case; a big chunk of the knowledge you grasp is [or should be] best practices, testing, clean code etc v0v

All good points. I'm not a NIH person so that has never been a problem. But I can be distracted by personal projects and work projects that are optional.

I have been focusing my learn at work activity on: - learning the languages I use better - learn the tools better (IDE, etc.) - and improving our software development processes

We have a long way to go on software development processes (best practices) because we are 100% self taught team that covers a diverse but not uncommon set of technologies (linux, apache httpd, javascript, jquery, angular, sass, java, bash, php, etc.) and we are always slammed with priorities for senior management of the university.

I do love filling in the gaps with learning. Sometimes I find something I learned a long time ago causes something else to fall in place and I think to myself "that is why I needed to learn that". Maybe a bit of serendipity.

I've been called "mastery-motivated" which means that I like to be able to accomplish what I want, when I want, better, faster, more efficiently, and more flexibly than anyone that I'm aware of. It honestly means that I hate introducing new things for novelties sake, and I would be happiest if the field never moved at all and I could get the job done in five minutes using something I wrote three years ago. Of course, it also means that if something five minutes old does everything in a better way than my old stuff, I need to know it now.

That's certainly not the same as passion for my work. It's more passion to get home and passion not to be a burden on my co-workers but a boon. Work is a place I go to make someone else money in exchange for as much as I can extort them into paying me.

summary: I agree 100% with Jack, but 0% with you, so I'm confused by your first line.

> If you were really "better than almost everybody else" you'd be hired to work on hard problems that even someone actually better than almost everybody else would find challenging.

That's assuming a lot. It's assuming that great programmers also make great career decisions. It's assuming that well funded companies or startups necessarily have the most difficult tech problems. It's assuming that the people who hired you to do really tough problems don't also have a huge list of "mundane" problems to solve as well.

I've had some really interesting problems and challenges to solve during my career. But every role also has a lot of boilerplate. I've found that what has really made me valuable isn't just my ability to solve the challenging problems, but also being able to see a project from conception to completion, even when you have to do the tedious and uninteresting tasks.

If there are a bunch of mundane tasks, the responsible thing to do is to delegate those tasks to a junior developer:

1. I'm happy because I don't have to do mundane tasks.

2. The junior developer is happy because those tasks aren't mundane for them.

3. Management is happy because the junior developer gets paid half as much as I do.

I disagree with this approach.

My policy as a tech lead (and then manager) was to spread the mundane tasks across the team equally. This let everyone experience the pain points and usually led to faster elimination of technical debt, since the senior developers would see patterns in the pain and find ways to address it. (Junior engineers often don't have the experience to recognize bad patterns or bad smells and would happily plow through a bunch of mundane tasks that could be done better with a higher level solution.)

It helped that we had a Tech Debt Week every 8-10 weeks where we took a week to fix problematic code and harden our deployment and automation processes. It was hugely popular with the engineers, we gave out trophies for the best fixes based on team vote.

The "share the love, share the hate" approach also meant that new junior developers were given challenging tasks as soon as they joined the team (and were paired with a senior developer for support). If they excelled, we gave them even harder things to work on. If they struggled, we found easier projects for them to work on and coached them through it so they didn't feel bad about their struggle--we always said it was better to try challenging problems and fail than attempt something safe and easy. Either way, we started new team members with the hard stuff instead of ramping them up slowly on the easy stuff.

The same policy applied to interns. They got challenging and impactful projects, no busy work or work the team didn't want to do. This meant we had a huge return rate on our interns and most of them joined our team when they came to work full-time.

No, the responsible thing to do is to build tools that do them for you, and then other tools that check they're being done correctly.

Failing that: often, products are made or broken on the ability to get the mundane parts done efficiently and properly. If anything, this means those parts deserve the attention of a more experienced engineer; otherwise, you'll end up rewriting them anyways, or at the very least spending more time in supervision than you would have to just write the damn thing. (And if you don't spend that time in supervision, well, you probably shouldn't be in a position to mentor anyone.)

I couldn't agree more with GP: good programmers are the ones who bring the same standard of work to the mundane tasks as to the fiendishly challenging ones. I'd go further: the best programmers are those who look at the supposedly challenging tasks and ask: "Why are we solving this problem? Is there a mundane problem we can substitute to achieve the same result?"

I spotted the same comment and chuckled.

Programming is never boring because it is inherently tied to the challenge itself: programming occurs at the very bleeding edge of new research and new challenges because. Everything that has already been solved for good has been implemented, so reuse or rewriting it is trivial. Programming is about turning an open question into an automated answer which moves the bleeding edge further each time.

In my experience, programming only gets more and more interesting because as we crack the challenges they level up all the time. I'm working on way more interesting, harder, and complex problems than what I was 10-15 years ago. The problem domain levels up, too.

A good programmer produces good code. The motivation or their personal feelings is absolutely irrelevant. Your comparison does not makes sense. There's no reason on his text to assume he's not a good programmer. We can say, that at least to his eyes, he's a very good programer, and that's all we know. The rest your saying comes from personal bias and generalizations.

Lastly, the programmer can make his decisions on financial grounds instead of "difficult problems". The most difficult problems are on academia, but not everybody goes to academia because the pay is low and the job opportunities are few.

All you're doing is pointing out a morality conflict, which really isn't an argument. A good person is one who the solves problems that need to be solved. This person said they don't care what problems they solve, so long as they prop up their own ego. That's hardly a position that the rest of us need to consider 'good.'

You could just as well be saying that someone who programs to hurt people and commit crimes can be a good programmer. They may be skilled, but 'good' is a more general term.

I think it's pretty clear that the quoted person means "skilled" when he says "very good". Good not only mean "what is morally right" but also "having a high standard". He didn't said a "good person", he said a "good programmer", it usully implies a "skilled programmer", not an "morally sound programmer". The same way a "good restaurant" don't usually imply that all their food is fair trade organic ethically sourced, but that the food is prepared with high quality.

Or he could be someone who has kids who he needs to feed, clothe and house. :-)

At this point, I'll be happy when I get a job.

>No, you're not a good programmer because there's no challenge any more. You're a bad programmer because you've lost sight of the context of your work.

I think you're being more than a little naive here. A very large portion of the software work that actually pays is, on a personal level, total BS. It's about helping a business do something boring in a much more efficient way than ever before. Or providing a service electronically that used to be done via snail mail. Or providing a way for bored people to make their commute bearable.

You can try and dismiss this as "turd polishing" but the reality is that if it was easy anyone would be doing it. I'm never going to be passionate about the product my company makes, but I still have the self respect to not produce terrible code that burdens my coworkers (and ultimately the customers).

In short: it isn't all about robots, spaceships and self-driving cars and stuff for most programmers. But we still gotta get to work.

> What makes you do the bits of work that are neither fun nor strictly necessary to get paid is that other people need it done, and you don't want to fail them.

I have a bad habit of classifying coworkers into "tidy" and "sloppy" ones. Tidy people for example take time to arrange code neatly, they care about coding styles and other things that are strictly unnecessary (sometimes to the extent bordering on OCD). Sloppy people are result-oriented: if it works, it is done.

The majority of coworkers that I can depend on are tidy people - in addition to caring about code formatting they are also more likely to go through all corner cases to ensure that the program actually works. But do they do it because they don't want me to suffer or because they want the job done neatly? Or because they don't want others to think of them as sloppy? I dunno. I guess it is a little bit of everything.

There are issues on both sides of that divide. I can't stand the tidy programmers who try and clean up ugly code that handles lot's of real world edge cases they don't understand.

Sometimes you can find loops in the source code repository where multiple people make the same kinds of changes to the same function before reverting back to the original state when some bug shows up again even when there is a comment about that edge case. It's one of the few times I feel leaving commented out code is reasonable, no don't do this it's not going to work.

The real world is messy, at some point you have to represent that twisty logic or it's not going to work.

I did not want to imply that tidy people are somehow "better". Of course they can screw up too. In addition to your example, wasting time on inconsequential things is a major sin.

My point is that in my experience dependability often comes loaded with these traits and I doubt that "love of thy coworkers" is the sole source of them.

If removing edge case handling doesn't make some tests fail, then poor test coverage is the root problem. Refactoring a code base without tests is always touching the third rail, neat or tidy, no?

You say that as if people don't remove tests while 'refactoring'. Better coverage = people ignore tests as they always fail. Worse coverage and they ignore tests because the tests must be outdated.

I write a lot of code that only I will work on in the future.

I keep it tidy because I don't hate myself.

Pre-commit code reviews quickly hammer all those different kinds of people into the same kind of nail. It's one of the best aspects of code review as a practice, yet it doesn't get as much attention as code quality and correctness.

It is worth putting the time into refactoring things properly and looking over every line of the diff to make sure it belongs on my team. If you do this, your code can often pass review with only a few comments, even for a change that's hundreds of lines long. If you didn't send good code out for code review ... god help you. You're going to be buried in dozens of comments ("the beatings will continue until the code improves").

There's certainly an adjustment process when people join our team and our company. But ensuring consistency across our entire codebase is absolutely worth it. And I know that I have become a better developer by consistently being held to high standards, and doing the same of others.

I like to think of myself as belonging to the tidy category, I value craftmanship, beautiful elegant code, what Torvalds would call good taste. I respect coding conventions. But sometimes, the manager comes in and says that the deadline was just tightened, and we need to release the thing earlier, so no more unit tests, some corner cutting ensues.

What's more, as my backlog keeps increasing, I can't build each component to the same level of quality without falling behind.

So I would say that it's not a black and white matter.

I tend toward the tidy side on things like this. I don't "have a reason", per se. In that regard, it's almost like an OCD, it's just something that needs to be done. (I don't have OCD at all, but this is just to illustrate.. you don't flip the light switch 100 times in hopes of some kind of reward, you do it because you're wired to do it).

Not sure how typical this is, but I suspect people who "just were going to do that anyway" will be drawn to roles where they have to or it's good practice. I'm pretty annoyed when deadlines or other stuff means I can't do that, and it's not about technical debt or anything else. I just feel like I'm forced to leave something half-finished, and it's annoying.

Interesting article. I fall on the love work side. It is always nice to see situations from multiple frames of reference however.

I left banking compliance almost 10 years ago to get back to web development and development management at a university and never looked back. I took a gigantic pay cut and left some serious grants money on the table. My health improved. My happiness improved and my now grown kids say I stopped being a grumpy dad. I've been able to be part of my family's life in seriously fun and meaningful ways.

At the bank I ran projects as the lead systems analyst and sometimes business analyst to bring some situations into compliance as viewed by bank examiners. I won corporate awards, had bank examiners exclaiming surprise at how fast and well the projects met or exceeded expectations.

But after killing a project across 7 business units for 3 to 6 months and working 70 to 80 hr weeks my boss would say thanks that was really great. Now here is another crazy can't really get this done but we need it done project.

So now writing backend code and running 140+ subdomains for a small university, I work most weeks 45 hours, love my team and the extended scrum team and only despise maybe 5% of my work such as performance management.

I'm nearing retirement (in 5 years) and am so happy I made this final career move. Oh I should mention, I am pretty good now at boxing my opinions and emotions about the stupid things that go on at a University. I see a lot of dysfunction at the cabinet level and think we are lucky that students don't get inculcated by these idiot savants.

Why did you work 70 hours? I've worked at two major us investment banks and both inculcated a full-time culture. Did you join the cult?

Really two reasons. 1) When I moved from IT to the Compliance side I did not realize what a bank examiner response project looks like in terms of timing and intensity. The examiners gave us a schedule and we had to fulfill on that schedule regardless... 2) At the time I was an all in person. 120% or 0%. After having chest surgery I came to the realization that I needed to slow down and enjoy life better. And I and so glad I had that chest event.

So I adopted a "less is more", "slow down to speed up" mentality and started looking for more satisfying employment.

You could sum it up as:

>Did you join the cult?

Yes.

Hah, thanks for your candid response, and I'm glad you've seen the light. Enjoy.

You actually sound like you fall on both sides similarly to the way I (TFA's author) do, seeing that you did high-paid less lovable work and then more lovable work for less pay. (At the moment I program 3 days a week and during the other days I animate without any plans to get paid for it.)

My point was mostly that one could be equally valuable (or, conversely, pernicious) at both types of jobs having either sort of motivation.

Working for the bank at times was very fun. I love problem solving and getting work done across large and small teams. But in the end my passion waned and it became a well paid job that was a burden. Thanks for the thought provoking post.

Interesting article, and a lot of it really rings true to me, though personally I experience this through a different slant.

I've been working remotely for this company for a while now, and compared to my previous job (which was on-site) the culture, management, practices, codebase, and attitudes are just far superior and healthier. Really in almost every way it's an objectively better workplace.

Yet, because it's so much more difficult to form meaningful friendships with remotes (you don't get to go out to lunch and chat about non-work stuff, there's no chance to hang out in non-work settings like after-work bars etc) many times I wish for my former job back just because my colleagues were my friends, there was an element of "brotherhood", and that just makes a huge difference. As humans I think our biological needs for belonging and kinship far outweigh our desire for craftsmanship and work. It also helps having interesting personalities as your colleagues.

Also, I get annoyed at companies and and interview processes which give a lot of weight to those who seem "extra passionate" about their craft and go to tech meetups, read lots of tech books, etc. I suppose it's something that's easy to screen for and gives a "feel good/look good" factor for the hirers, but it completely eschews the idea that one's desire to work might not be for the passion of the work itself; not to mention it often doesn't turn out to be that accurate of a filter when it comes to actually working on production apps in a business setting.

I met a guy I studied with recently, he found my blog and invited me to dine together. It turns out he managed a team of remote workers, and he ranted how those office buildings where you catch infectious diseases are a thing of the past (he also freaked out when I sneezed.) However he also wanted to meet various people from our joint past, like he just met me, which was kinda weird given that we were never best buds or anything, and I think this ought to have to do with a shortage of time spent in office buildings where you catch infectious diseases.

Personally... I'm not smug about this at all, I'm the opposite of smug; because the stuff I'm doing in my spare time of which I now have more does not involve such an office building and I really wonder whether a void will form there.

I become irritated being told how I'm supposed to feel about a job. The reality is that a good number of people don't have opportunities to do something they truly like doing. Most folks would do something completely different - or at least work on different projects or give the bits they don't like to someone else - if they could just simply do what they love. I highly doubt anyone would clean toilets or wash dishes.

But some folks don't mind doing that sort of thing so long as they bring in income, preferably enough to live off of. And some of these folks take some satisfaction that they have done their job well, even if they don't like the work. And they can treat each other well.

I'm never sure why this isn't enough. So long as one doesn't hate the job and it doesn't make life miserable, i'm not sure why it matters if someone has "passion" or "love" for their work. I highly doubt people could tell the difference anyway.

Because employers prefer candidates with "passion" over ones without, all else being equal. Which makes sense, given their incentives.

So, given that reality, employees learn that demonstrating "passion" gets them more job offers than not doing so, so they do what they can to appear "passionate". Which also makes sense, given their incentives.

So you end up with a system that looks ridiculous, but it's just groups of people following their respective incentives.

It's not that a sensible work ethic isn't enough, it's just that when the next guy is promising more than "enough", you're less likely to get picked.

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.

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

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.

[1] http://www.potw.org/archive/potw351.html

Agreed!

Some people say they are looking for "passion" in a job candidate. I don't want "passion," I want three things - can you do the job? Can you work well with others? Do you have a good work ethic?

Save the passion for outside the office. Nobody asks a coal miner how passionate she is about coal - you don't have to have passion to do a great job.

I based this from experience. Some of the best coworkers I have are the 9-5, just a job crew.

I suspect there's an anti-passion meme around at the moment beyond this article? Perhaps not, but my young friend who is all over the social medias recently talked about how the word "passion" is redundant and overused. I agreed, and will no longer use the word on job applications. The awful truth is probably that any passion I had is now worn down to a dull weathered surface. Luckily I'm into weathered surfaces so it's all good.

Not that I know of. It's just tons of people who write about interviewing say they are looking for candidates with passion. This is actually the first time I've personally seen someone arguing against it.

I suspect passion is a proxy for youthfulness.

This is so on point about one of the toxic corners of engineering culture - the strange insistence that only those who love programming above all else in life can be good at it.

Aside from being a great way to squeeze extra hours out of naive new grads, it's just totally off base. As this blog post touches on, one can TAKE PRIDE in one's work and be motivated to do a great job without having to love it.

The lady who cleans my apartment once a month does an amazing job, unlike the 5 or 6 people I tried before finding her. Is she passionate about cleaning bathtubs? Of course not. But the difference between her and the others is that she takes pride in doing it superlatively.

And that's how I hire engineers too. I really couldn't care less about whether you're an [X] developer because you love the technology or because it's a steady paycheck that feeds your kids. What I do care about is that you're considerate towards the people around you (and that includes the people who will come after you) and that doing a good job is important to you.

Not everyone has the opportunity to do something they're passionate about. And if they could, we'd have a world with an enormous shortage of both programmers and janitors. But everyone has the opportunity to CHOOSE to take pride in doing a good job. It may not be inspiring, but -- speaking from experience -- even if you're flipping burgers you can make the job more fulfilling (or at least less soul-killing) by caring about doing it well.

Interesting article.

Just a note on the biblical reference: The moral angle that thinks it is important to love your work comes from a more protestant view of the Bible. Martin Luther defined that wordly work is a duty that benefits the individual and society, it is an extension of the concept of good works in catholicism. From a protestant perspective, work ethic is very important, because the "good works" are not only charity work, our wordly daily work is a work of mercy as well. It must be done in benefit of society. Even though it is a more lutheran concept, it is very influential in the states, the "self-made man" myth, the importance of the person that goes up the social ladder on perseverance, is very influenced by this protestant ethic. So, the view of love thy colleague, but not your work, is more akin to a catholic thinking. Countries that have a very strong catholic tradition such as spain or ireland, tend to have different work ethics than germany or the netherlands.

I've never lived in either a Protestant or a Catholic country (I've lived in an Orthodox country and a Jewish one), so the following guess isn't based on much first-hand experience, but I'd guess that "love your work" in the Protestant sense is probably closer to what I mean by my tongue-in-Bible "love thy coworker" than to "program for free during your weekends and publish code on github." That is, "work ethic" - yes, but because that's the proper way to get things in return for things in a society, not because nothing is more fun than neural monadic closures.

Got bad news for you buddy - money or Love, you can't have both.

Liking your work helps you through downtimes. Tech has had a long enough boom that the newbies havent experienced an industry wide downturn. Its happen before and could happen again.

This is one of the best pieces about work I've read in a long time.

Everyone should love their work, deeply. If you don't, then you should demand work that you do love. If it's impossible to get work that you love, then you should change the world.

You're joking, right?

I'm laughing. That surely sounds like inspirational stuff, but it is crap advice. Most folks are just stuck choosing from what they can get.

Besides, it is really irritating being told how to feel. It just makes people fake it to make their boss happy. You start hearing this sort of thing in low-level retail jobs, where you go home and don't want to pretend happy and love for work any longer. Very demoralizing stuff.

I'd much rather people focus on doing well in their jobs, everyone, helping others out if they need it, and treating coworkers well. This is realistic to most workplaces and makes even mundane work not nearly as horrible to repeat for hours and hours and hours every week.

Reply on news.ycombinator.com