logoalt Hacker News

remuskaosyesterday at 5:08 PM1 replyview on HN

I studied physics, did a PhD and postdoc, the whole science shebang. When I got into software development a few years ago, I was put into a well functioning pizza sized team that developed an internal app for another company. The crew was as software-dev as it gets,:

- one architect who was there from the apps inception yen years prior, who knows all the ins and outs of the application - one project lead, who was with the project two years, who could also code in the classical sense, but was mostly the connection to the customer - a tester who could not code, but also knew the app in and out (from the user perspective) and found things or relayed and reproduced bugs reported by the customer - a technical writer who could also code (somewhat), but was more responsible to think of user behavior, undefined app behavior, edge cases, logic issues etc - and several disposable code monkeys, who were exchangeable and expendable, who did most of the tickets. I joined as one of these

The work was great, the team functioned great and we delivered what the customer wanted. But what really struck me was that software dev is not science, or engineering, or an art form, it's most akin to a trade like plumbing or carpentry. I had computer science as minor in university and pretty much none of what I learned there helped for "real" work. I learned SVN in university, but obviously the team used git. And all of the software development and programming courses I did taught me nothing of how real software is structured or how a team works.

That impression only more strongly once I had to train new hires, PhDs in comp science, who knew basically nothing about real software development.

Again, it's a trade, something you learn on the job from someone who already knows it, like a master carpenter.


Replies

dcrazyyesterday at 7:02 PM

Heh, that idea resonates with me. I’ve been contemplating some projects that will require pulling permits, and as part of that process have been trying to understand how an engineer reviewing my submitted plans would think.

While you could absolutely generate a list of compliance checks to execute like a formula, at the end of the day you need to have absorbed enough experience that, when presented a physical or imagined project, your brain is immediately able to make connections between what it sees and the general principles of how you build something correctly.

Since I don’t have that experience, I know I need to stick to the well-trod path. No clean-sheet deck construction methods for me. :)