← Back to context

Comment by taneq

1 day ago

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.

      2 replies →

  • Handyman might be better analogue. And fixing should be either change some parts inside the toilet bowl or swap whole thing. What a software engineer would do is teardown bathroom with half a building and build a new annex with squat toilet...