Live data from Hacker News

The dispassionate developer

blog.ploeh.dk

121–130 of 262 posts

Re: The dispassionate developer

#121
I'm shamelessly passionate about software development, but I don't project it being a big part of my life forever and ever.

For example with covid, I have fewer other possible hobbies so doubling down in this specific interest is both fun, and a sound investment.

And also age/trajectory matters. I'm at year 10 of my journey, probably around year 20 I'll have completely different priorities in my life.

Re: The dispassionate developer

#122
post #102

Earlier quoted context omitted.

Thank you! When I was single I had a lot of free time to tinker and go through coding tests, etc, etc, and cater to whatever hiring shenanigans were in place. First marriage, then a kid, and I find myself grabbing my laptop after work maybe once a fortnight. I'm always "open for new challenges" and I regularly apply to positions in interesting (to me) projects, but more often than not, at some point in their process…

I wrote open source initially because I wanted to skip those assignments but still be fair to the hirers and because it took less time and was WAY more fun than take home tests. What I discovered was that they'd be willing to make me work 5+ hours on their assignment but wouldn't spend 5 minutes reading my code. Though it wasn't my intention it inadvertently gave me a quick and easy way to filter companies which acti…

It takes more than five minutes to review code, especially when it's of a volume you describe. You're also really trying to replace the metrics against which a company measures candidates and insert your own metric and then complaining that they don't use your metric. I wouldn't expect you to use my metric when interviewing me for your company, so don't think it's fair to try to insert your own metric for others (though you're welcome to vote with your feet).

Re: The dispassionate developer

#123

> If you're tired of working with legacy code without tests, most of your suggestions for improvements will be met by a shrug. We don't have time for that now. It's more important to deliver value to the customer. This is what bothers me the most. Whether it's about tests or something else. Even clean slate "let's get everything right this time" projects degenerate into legacy code within weeks with this mindset. The…

I have seen this be the fault of developers as much or more than management - even for that "let's get everything right this time" sort of project, devs who interpret that as "let's build a beautiful intricate machine that does exactly what we want it to today" are fare more common than devs who build something that will be able to evolve for tomorrow's needs. Management rarely is involved or interfering there, when…

I believe there's a way out of this and I've seen at least one successful attempt - it's having regular group practice/rehearsals/drills/wargames or, to put it in a more familiar term - internal projects.

On one hand developers get to scratch their "ooh new shiny" itch, on the other management doesn't risk any deadline from people trying new ideas when there's no time for that.

Unfortunately few employers are willing to go this route due to the associated cost.

Re: The dispassionate developer

#124
post #16

Earlier quoted context omitted.

Taking that a step further, we often actively discourage looking at OSS contributions during resume review for the same reason we don't offer take home interview assignments: it's biased against people who don't have a whole lot of extra time at home. When we have done either of the above, the singles who work part time have a bunch of time to perfect their work suddenly have a lot to show over the single parents who…

We're having a bit of a debate about this internally as the company I work for is struggling to hire good candidates. For a while we've had a take-home test and that has increased our success rate somewhat. But as you say, we really don't want to lay unreasonable expectations on people who may have other obligations, but we've had many people in the past who've interviewed very well but turned out to be completely in…

> We're having a bit of a debate about this internally as the company I work for is struggling to hire good candidates.

What's the compensation like? Stock?

> For a while we've had a take-home test and that has increased our success rate somewhat. But as you say, we really don't want to lay unreasonable expectations on people who may have other obligations

You'll also find out that the people you really want to hire are not on the market for a long time. So if they are interviewing at several places and you give them a 4 hours take-home, they'll put it on their to-do list but by the time they get to it they might be in the final rounds at 2-3 other places that brought them on-site immediately.

> It probably doesn't help that management here is almost entirely non-technical

That's a much bigger issue than most assume.

> There's usually a developer or two sitting in on the interview to try and balance it out

That's a huge no from me. Final approval of a technical candidate should only be in the hands of the technical staff.

I've heard horror story of a "senior" engineer from "his country's top school" being interviewed for a technical position by several non-technical managers and HR reps. They only included an engineer in the final round, which was basically supposed to be rubberstamped anyways. He was then asked to implement something trivial like fizzbuzz or wordcount on the whiteboard. The candidate then became extremely defensive and tried to argue that such task was "beneath him", arguing for a good 15 minutes why he shouldn't have to do it.

Then the dev just left the room and said that he used this question as a warmup with new hires and it typically takes them less than 10 minutes.

Re: The dispassionate developer

#125
post #109
post #57

> ... employers want employees who are passionate about their craft. > ... I'd like such people to care about their vocation, but I'd prefer that they keep a cool head and make as rational decisions as possible. > Why should programmers be passionate? While I agree with the gist of the article, the author should realize that "passionate" as used in this context is effectively synonymous with "cares", and is only used…

100% this. I don’t expect you to go crazy over programming, but the gulf between passionate programmers and just-collect-the-paycheck programmers is extreme. Just-collect-the-paycheck programmers are useful and necessary, but a team composed exclusively of uncaring engineers is pretty much doomed to fail. Lightbulbs are flashing for me right now because I’ve never really thought about it like this, despite caring a l…

> a team composed exclusively of uncaring engineers is pretty much doomed to fail

Yes, but not because of the lack of passionate programmers, but because most software companies are dysfunctional. A few passionate souls can make a project succeed in spite of all the underlying dysfunction, but it's cruel of the industry to continue leaning on those people.

Teams of uncaring developers would consistently deliver working software on time and on budget if they were both trained in the same level of skill and given the same level of respect that let uncaring civil engineers build stable bridges on time and on budget. And I would certainly hate living in a society where the only thing between me and a smoking hole at the bottom of a gorge is one passionate civil engineer.

Re: The dispassionate developer

#126
post #90

Earlier quoted context omitted.

That's wonderful! You sound like a very driven person to be able to do all of that. Of course, your experience and ability shouldn't be considered the norm with everyone or expected of anyone, especially because with finite time in the day and differing situations, we must strive to judge everyone on the same plane.

> Of course, your experience and ability shouldn't be considered the norm It is the norm in my line of work. I mean in my other line of work that isn't a software development.

Oh sure, sorry I should have clarified, I was talking about software development. I thought that was implied, but happy to be explicit.

Re: The dispassionate developer

#127

Maybe it's the jobs that I've worked, or the country I'm in ( UK ). But I've really not seen this shift towards looking at portfolios of open source work rather than CV's. Every company I've worked for has requested a CV, and often does some form of test or in person interview centred around programming problems. The tests vary in quality and depth. I wouldn't think of myself as a passionate developer. I have a famil…

> I wouldn't think of myself as a passionate developer. I have a family, I value my free time. I spend work time growing my skill set as it's required, anything else I do is rarely related.

Clearly you've never met devs that have no passion. They will actively refuse to learn new things and have absolutely no interest in doing so.

If you look at other professions, growing skills and staying up do date is supposed to be done during working hours and is budgeted for. A lot of 10x I've met were parents and had a pretty strict schedule. Whatever time they had in the office was 100% dedicated to shipping results or growing and they had to be efficient at it because there was no way they would spend less time with their families.

Re: The dispassionate developer

#128
post #16

Earlier quoted context omitted.

On the hiring side, it’s rare to see someone come through with significant OSS contributions. A small bug fix here or there is about the most I see from 90% of resumes. Every once in a while we see someone with a lot of open source contributions, or even full leadership of a popular project. These people would really prefer if we believed that OSS contributions and GitHub profiles replaced resumes or CVs, because it’…

Taking that a step further, we often actively discourage looking at OSS contributions during resume review for the same reason we don't offer take home interview assignments: it's biased against people who don't have a whole lot of extra time at home. When we have done either of the above, the singles who work part time have a bunch of time to perfect their work suddenly have a lot to show over the single parents who…

> we often actively discourage looking at OSS contributions during resume review for the same reason we don't offer take home interview assignments: it's biased against people who don't have a whole lot of extra time at home. When we have done either of the above, the singles who work part time have a bunch of time to perfect their work suddenly have a lot to show over the single parents who may be working full time or more.

Or their company ships a product that has a huge dependency on that particular OSS project, so they are doing the work on company time.

Re: The dispassionate developer

#129
post #82

Earlier quoted context omitted.

> we've had many people in the past who've interviewed very well but turned out to be completely incompetent when assigned to a real project. Unpopular opinion on HN: This is actually quite common when you hire based purely on resumes or credentials. Some people are really good at interviewing and being charismatic enough to convince people to hire them. There are a lot of candidates who can talk the talk but really…

What you may be missing is how hard it is to actually create a good take home. Every take home test I’ve seen was rife with potential for the problem to explode in complexity. Even things that seem simple like names and dates have so many potential pitfalls that it can be impossible to tell as an applicant whether they intentionally laid a trap or not. Then there’s the incidentals, should I send them a docker image t…

Take homes are easy to iterate on. If multiple candidates can’t understand the problem or waste time with over-complicated solutions, you update the instructions.

If you’re constantly worried about “traps” then you might not want to work for those companies anyway. Take homes should be straightforward and similar to solving real problems.

> As far as I can tell, any company that isn’t willing to pay contracting rates to solve real problems on their stack is likely being disengenuous with their take homes

Take homes are contrived problems, not real work. Every candidate receives the same problem so they can be compared.

No company should be giving employees actual unpaid work to do as part of the interview. That’s more of an internet trope than a real problem because no rational company is going to be sending their codebase to applicants to add features to.

Re: The dispassionate developer

#130
post #102

Earlier quoted context omitted.

I wrote open source initially because I wanted to skip those assignments but still be fair to the hirers and because it took less time and was WAY more fun than take home tests. What I discovered was that they'd be willing to make me work 5+ hours on their assignment but wouldn't spend 5 minutes reading my code. Though it wasn't my intention it inadvertently gave me a quick and easy way to filter companies which acti…

It takes more than five minutes to review code, especially when it's of a volume you describe. You're also really trying to replace the metrics against which a company measures candidates and insert your own metric and then complaining that they don't use your metric. I wouldn't expect you to use my metric when interviewing me for your company, so don't think it's fair to try to insert your own metric for others (tho…

It takes more than 5 minutes to thoroughly review code but you can learn a lot from only spending 5 minutes.

Ignoring it completely also sends a signal to the candidate. IME this red flag is usually paired with 5 or 6 other red flags.

Post reply on HN