Live data from Hacker News

The dispassionate developer

blog.ploeh.dk

91–100 of 262 posts

Re: The dispassionate developer

#91
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…

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

This is just another single dimension hiring credential, that will result in limiting your hiring pool to people like yourself. My code ran on 70+ million machines last month, but I've come to decline any timed or proctored technical interviews.

It's not that I'm too good for whiteboarding or timed tests, or that my options are so open that there isn't significant cost in doing so - quite the opposite: I'm come to find the process so traumatic that going through with it isn't worth it for anyone involved: those jobs just aren't open to people like me.

Re: The dispassionate developer

#92
post #33

I do like when teams will ask for side projects (if I have them) or OSS projects. Software has an inherent bias towards people from prestigious schools (but especially CS programs) and enforces that bias via heavy algorithm testing that is otherwise mostly not needed in software. Not to say it's never needed, but the 90% use case does not involve knowing how to do binary search by hand. As I built my knowledge around…

> Software has an inherent bias towards people from prestigious schools and enforces that bias via heavy algorithm testing that is otherwise mostly not needed in software. Can't any school teach the same algorithms material? It's not exactly secret. Algorithms interviews seem more like surreptitious IQ tests than anything else.

Any school can teach the same algorithms material, but not every school allocates or requires comparable amount of time and effort to that material. Some schols will just point you at the material and test if you rememeber the basics, and some schools will outright flunk you unless you practice until you can write correct implementations of all that material quickly with your eyes closed.

Re: The dispassionate developer

#93
post #60
post #51

Earlier quoted context omitted.

>I say "often" because OSS contributions can still be an indicator of something, but it's not really clear what. It's a fairly clear signal of skill quality and attitude. Reading open source commits/PRs and issue trackers tells you quite a lot about a developer which you can't see without some sort of a test (often not even then). >it's biased against people who don't have the time Surely any career that requires a h…

It's not about merit but about bias

So you'd consider it anti-meritocratic?

Re: The dispassionate developer

#94

This post makes some good points. But I think there's another extreme we need to be careful to avoid. In a world full of workers who are emotionally and morally disengaged, just doing what they're told for a paycheck, there's plenty of room for exploitation of a different kind. Perhaps the best model for software development is a small company with a few cofounders who are passionate about what they're working on, wh…

> In a world full of workers who are emotionally and morally disengaged, just doing what they're told for a paycheck

I don't this is true of software. I live on the West Coast and SWEs are by far some of the most vocal and aggressive voices in a crowd. They seem highly engaged and constantly channeling emotion for what they want. That said, it's a recent trend. When I came into software the attitudes were much more laid back. I'd prefer a return to this.

Re: The dispassionate developer

#95

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…

In Australia, and I concur. No one expects you to have OSS contributions and it's enough to have work experience.

Thank goodness. I didn't spend all these years working for it to be ignored in favour of a few hours a month patching people's shit for free. My work experience is also 9-5 week after week of solving real business problems, which can be messy and requires pragmatism. Just working on OSS doesn't prepare you for work, it's a great start, but OSS projects are often very clinical, perfectionist and academic. Work has messy business requirements, legacy code and the need to deliver good work in a timely manner.

If I had to start as a new developer again, I would still just do pet projects, not OSS. You can be very targeted in your demonstration of skill with a pet project intended to get you a job.

Re: The dispassionate developer

#96
I used to be someone who did programming outside of work, but I don't have time with a kid, and further I don't really want to spend time fixing anything electronic any longer. I just use a console for gaming, my computer sits unused and I only use my work pc for work, so I barely even go on the internet.

Parenthood takes a lot of time, and I fear I'll never be able to find a new job because i don't have time to jump through interview hoops.

I'll certainly never work at Google or wherever, because they interview for so long and have so many requirements that it's impossible for me to even think about applying. The tech interview process is openly hostile to parents.

Re: The dispassionate developer

#97
post #77

Earlier quoted context omitted.

That wasn't my point. You have to make a living, and in that regard fun is a nice-to-have. My point was even things people do for hobbies often become toilsome once they are your business. My neighbor has a job unrelated to carpentry, and woodworking is his hobby. He doesn't want to ruin it.

And I'm saying that I made Android apps as a hobby and now that I work as a dev, I don't see any point to continuing as a hobby.

If you still want to code as a hobby you could do "programming" opposed to "software engineering" as someone in this thread has pointed out. Personally I could see making web apps with a Web 1.0 design as a fun project although probably I would still structure projects "professionally" :)

I get that it's not much fun to code apps (which I did for fun, too) because you need to do some kind of marketing to get a user base because if you don't it's not much fun to have an orphaned app in a store.

There's still a place for fringe programming if you feel the urge. Or go fishing or do gardening.

Re: The dispassionate developer

#98
> What can you do, then, if you want to stand out from the crowd? How do you advance your software development career?

I'm sure there are other ways, but one sure way that I have personally used and been fairly successful. Understand your boss and make your boss look good. If you don't understand your boss by year 2, it's time to move on.

Re: The dispassionate developer

#99

Earlier quoted context omitted.

It's not that they make use of open source. It's that some have the gall to expect developers to contribute to open source in their own time, rather than working on their own projects or contributing to open source on the company's dime (the last one being, by far, the best option for humanity as a whole in a vacuum). Though the main problem is in companies expecting too much from their employees (see: "looking for s…

I don't expect my employees or candidates to contribute to open source, but the curve of those who do is shifted to the right in my opinion over those who don't. (It's the practical part of why I fight for HR policies to allow continued contributions to open-source, even unrelated to work: because otherwise I close myself off to that subset of the population, in addition to my philosophical stance of 'what you do out…

[deleted]

Re: The dispassionate developer

#100
> 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 "It's more important to deliver value to the customer" line is especially insulting, since it's not as if the developers are trying to sabotage the delivery of value by writing tests or sanitising input or whatever the conflict is about. We know that high quality code is faster and cheaper to build than low quality software, but it's counter-intuitive to most managers.

And you need sympathetic managers to get the software right. Business rules are rarely clear, orthogonal or consistent. Which is not actually a problem for humans, but until we have artificial general intelligence, it is an insurmountable one for computers. But unsympathetic managers will not want to have long, uncomfortable conversations about deducing what they actually need from what they think they want. So developers are instead forced turn messy rules into messy code as best as they can, and put out fires whenever they break out, which they will all the time.

And perhaps the most insidious thing of all, spending all the time putting out fires means they don't get real world experience they need to build a robust system on time. If managers let them try once it would just make them look incompetent. And if they quit, their experience putting out fires will be worth nothing to companies who actually value proper workmanship. Their only option would be to join another death march company.

I think this the biggest reason why most software, especially enterprise software, is so bad, and isn't likely to improve in the foreseeable future.

Post reply on HN