5 ms·

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

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 https://en.wikipedia.org/wiki/Automotive_Service_Excellence

pjmlp 7y ago
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.
Spooky23 7y ago
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.
maximus1983 7y ago
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).
- avgDev 7y ago
  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.
  - hombre_fatal 7y ago
    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.
  - rpz 7y ago
    > 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.

pjmlp 7y ago

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.

Spooky23 7y ago

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.

maximus1983 7y ago

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

avgDev 7y ago
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.
- hombre_fatal 7y ago
  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.
- rpz 7y ago
  > 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.