Hacker News Reader

Hacker News

Comment by degenerate | Hacker News Reader

Parent Full thread

degenerate

I've heard the analogy of a software developer to a mechanic, and I like it much more.

Developer = Mechanic

Computer = Car

Make = Language

Model = Platform

Year = Version

A mechanic is licensed by ASE to work on cars in the USA and there are 50 different certifications [1], depending on the type of car/truck/bus. I don't want to see software development go this route, where developers have to get multiple certifications to prove they can work on a language or platform. It would be draining and force devs into silos, even more than they already are. And as the parent comment mentions, software is an "idea" problem and not a structural/foundational one. Unless your developer is a certified genius, what good is his certification?

[1] https://en.wikipedia.org/wiki/Automotive_Service_Excellence

View on HN

It is already like that in the enterprise, where certifications are the entry point for certain partnerships.

As engineer I find there should be a baseline.

I also don't expect weekend cooks to keep a Michelin restaurant running.

I don't like car analogies.

A software engineer is like a plumber you link up lots of small components, weld them together and then the data flows through the application (at least that is the idea).

I don't like either of these analogies. Work of SE is much more complicated. I guess a developer who just mashes things together on the front end is kind of like a plumber.

However, if you work with the backend, you need to worry about data access, any concurrency issues, performance problems. Generally tradesman follow relatively simple guidelines, which may change at a slower pace....tech on the other hand changes insanely quickly.

You don't "need" to do any of that on the back-end either to launch a product. Not sure what distinction between FE and BE you think there is here. One messes up an application on the server, the other messes up an application on the client. And there are plenty of avenues for being a clueless plumber on the backend, like using Ruby on Rails + "gem install devise" for authn + "gem install carrierwave" when the boss tells you they want avatars, without having much idea how anything actually works.

> I don't like either of these analogies.

I think it's hard to find a good analogy because software is an incredibly organic and artful thing. It can be highly technical but also playful.

I think it's a matter of finding the right people for the right job, and making sure those people have some skin in the game. If there is no incentive to write quality code, or the dev's don't care to write quality code you probably won't get quality code.

Then again maybe we still haven't come across the correct tools for the job that make it easier to produce quality software.

The fundamental architecture of a car has been relatively the same for many years now. To a lesser extent we see that in computer hardware however in software it so easy to invent new tools that maybe the good tools get lost in the mess of it all.

That happens already. As things stabilize you tend to value predictability. You can have 6-10 smart people do the architecture and design work that drives the work of hundreds of developers.

Programmers want programming to be about ideas, but many/most problems are applying patterns to process.

Reply on news.ycombinator.com