Comment by arealaccount
Comment by arealaccount 2 days ago
In the same way a nascar driver isn’t hired to drive, but hired to win races.
Feels sorta pedantic.
Fun read nonetheless.
Comment by arealaccount 2 days ago
In the same way a nascar driver isn’t hired to drive, but hired to win races.
Feels sorta pedantic.
Fun read nonetheless.
But they're also not hired to simply "win races". You don't hire them to tinker with the car's engine, invent a tire-traction-enhancing additive, lobby for rules changes that favor your team, subcontract the driving to a better driver, or play loud music to disrupt the sleep of the opposing drivers on the night before the race. You hire them to drive the car well enough to win, because driving is the skill you hired them for.
You don't hire them to drive Ubers, sure, and likewise you want your programmers to be building things of high value. But you also don't expect them to just walk into the CEO's office, sit down in the big chair, and say "Actually, rather than writing code I can contribute more value from here, so today I'll do this job."
Here's a less pedantic version:
An academic researcher isn't hired to do research, but publish papers.
Similar to TFA, I think the issue is more about alignment than anything. Goodhart's Law creeps up slowly and can destroy any business or industry. Both can also stay off alignment for an uncomfortable amount of time. In our research example, I think it is clear we want our researcher to actually be doing research and that paper publication is a (measurable) natural result of that work, but it should be a bit more obvious to see that there are ways to increase your publication rate without increasing your research rate (or even increase your publication rate at the cost of your research rate). (Obviously I disagree with TFA's point)
The driver helps create revenue the car owner (often in the form of ad dollars). They may do this by driving well or they may do this by dating a country superstar or starting fights with other drivers.
Sure at the end of the day driving is a big part of it, but it’s not the only thing.
There’s what, 40 cars in the Daytona 500 and 39 of them lose. Are those 39 bad at their jobs?
I know nothing about car racing and I’ll prove it: until your comment I always vaguely assumed that the number of cars in the Daytona 500 was…500?
I don't think it's pedantic at all. Your NASCAR driver is hired to win races, not to drive. If they drive on the highway, or down to the shops, or at the track when there isn't a race (or qualifying, or testing, etc.) on, or they drive a different team's car, or their own personal car, then they might be driving but they're not doing their job. Their job is to drive that particular team's car in such a way as to (directly or indirectly) win races.
In exactly the same way, a software developer isn't just hired to write code. We're hired to solve problems. We usually do that by writing code but that's not always the right approach. If your employer told you they wanted to be able to control a Windows computer from a different computer in the next room, I hope you wouldn't start writing code, you'd just show them Remote Desktop (or VNC etc.) If your employer wanted a web dashboard for your product, you might write a bit of code, but you'd try and find some existing dashboard project with an appropriate license, and hook your product's metrics up to that. Writing code is a tool, of course, and if there's no better way to do a thing (like if you're developing a new product) then writing code is going to be necessary, but a lot of times it's a tool of last resort.
if you hired a plumber, and asked him to fix the toilet, you expect him to fix the toilet.
You don't expect him to tell you your whole house's plumbing sucks, you have lead pipes and to properly fix the toilet you need to replace it all.
Just do the smallest, cheapest thing to fix the toilet.
Replace 'fix the toilet' with 'writing code', for programmers.
I would absolutely love for the plumber whom I hired to fix my toilet to let me know what other crap I missed in my house's plumbing. Just doing the smallest, cheapest thing to fix the toilet is sometimes desirable but if it's just going to cause issues again soon, or if there are other issues I'm not aware of, I'd better at least start planning for those!
But software engineers are tasked with solving business problems. Ofcourse writing code is part of it. But other things too, for example communicating with users to understand requirements better, which lead to a reduction in scope, which reduced the code to be written.
Or sometimes it is found that a good solution can be devised but which satisfies about 80 percent of the requirements, and it may be prudent to attempt to negotiate to remove the 20 percent requirements which cannot be satisfied.
> But software engineers are tasked with solving business problems.
i would imagine that a business owner may want to hire a business analyst to undertake such a task, rather than a software engineer. Someone ideally with domain expertise in such business problems.
A software engineer is trained to produce software, given a set of requirements. If this software engineer is also tasked with gathering these requirements, which somehow, is increasingly the case now-a-days, then he's doing more than the job of a software engineer - he's also doing the role of BA.
More in the manner a foreman is hired to deliver cars to end customers.
A nascar driver seems like overkill, competent drivers that can deliver cars without speeding, truck drivers that can load up and move 10 cars at a time, managing a team of subcontractors who can drive on demand as needed, etc. all seem like better options.
> Feels sorta pedantic.
Absolutely not. A Nascar driver isn't hired to drive to the grocery store. Or to run errands. Their not hired to drive leisurely. They're not hired to be the safest driver. They're not hired to drive the absolute highest speed either (and crash). Their hired to win races. And it's important to understand that.
The difference is that in Nascar it's very visible to everyone when a Nascar driver is driving in a way other than what they were hired for, it's not as clear for a programmer. Not to mention success as a programmer also means doing many things other than programming, including knowing when to say "we shouldn't build this".