Live data from Hacker News

Ask HN: How to transition from academic programming to software engineering?

news.ycombinator.com

81–90 of 105 posts

Re: Ask HN: How to transition from academic programming to software engineering?

#81
post #80
post #56

Earlier quoted context omitted.

Yeah, software engineering is a craft, and generally the only way to learn those fast is to learn from others.

It's not a craft, in its purest form it's an engineering discipline with specific rules, procedures and standards. The crucial point is that most of us a doing programming, and not software engineering. Learning from others is hit or miss. One can certainly learn to program from others, but that's not enough to be able to do software engineering.

Convince me that its "purest form" is an engineering discipline rather than a craft. What distinguishes it from things that you would agree are crafts? Or are all crafts actually engineering disciplines in their purest form?

I think this is a pretty interesting question. Personally, when I was young, I would have said what you said: it's engineering, specifications go in and properly engineered finished product come out. I was proud that my CS program was contained in an engineering school and that all my friends were in other engineering disciplines. The longer I do this though, the more I think it's a craft: fuzzy idea is put to a skilled practitioner and through discussion and creativity, one or more artifacts are created to satisfy that idea. You could argue this is true of more traditional engineering disciplines as well, and I would probably agree. I'm not totally sure what the distinction between the two things is. So tell me what the distinction is and convince me what we do is more the one than the other.

For what it's worth though, apprenticeship is also a very important part of engineering education. At some point, you have to see people do the thing, regardless of whether it's engineering or a craft.

Re: Ask HN: How to transition from academic programming to software engineering?

#82
post #54

Earlier quoted context omitted.

I've written software over a decade and I loath the design patterns book. I would not give it to a beginner as it would corrupt their mind with useless drivel . It's authors exhibit themselves as morons who celebrate renaming existing computer science concepts while occasionally mixing and matching them. I would not be this uncharitable towards it if it was not such a famous (and hence harmfull) book. It's harmfull b…

Your comment is very interesting. I recently took a course on Design Patterns. I sat squirming during the lectures because I didn't like what was being said, but couldn't put my finger on what exactly I disliked. What I understand from your comment is that you dislike the Gang of four book because it renames concepts that don't need the cutesy names that they give them. Do you have a problem with the _concept_ of des…

your instinctual reaction against design patterns because you may have realised that design patterns are patches over flaws in the programming language's design - they're a terrible basis to build an architecture on. There's some discussion on this idea at the C2 wiki: http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures

Re: Ask HN: How to transition from academic programming to software engineering?

#83

Earlier quoted context omitted.

I would also add that lots of new people waste more time doing TDD wrong than they would save doing TDD right. There are lots of things you only really understand until you've done them wrong.

Yeah, a lot of software engineering schools of thought are just based on superstition, but they're all somewhere in the neighbourhood of "productive practices" regardless of how different they are from each other. If you do * 100% pairing, * buttloads of unit tests, * lots of microservices, * use an autoformatter, * in a Node codebase, to order-of-magnitude approximations you're probably going to be about as effectiv…

Whoa I just read about Harrison Bergeron on wiki [0]. That was an interesting read. I'm sure the full story would help capture a lot more of Harrison's spirit and qualities

[0]: https://en.wikipedia.org/wiki/Harrison_Bergeron

Re: Ask HN: How to transition from academic programming to software engineering?

#84

I have hired some PhDs in your situation and worked with others, I personally just went to work after I got my BSEE. My observation is that you're halfway there when you realize that you need to improve, of the folks I saw who did poorly it was because they didn't realize that you could be both the smartest person in the room and the least capable at the same time. Right now, on your first job experience, even a kid…

This is pretty good advice overall. One small change I suggest is to take it easy on Design Patterns and the like. I’ve seen people in OPs position (general smarts but limited production experience) turn into architecture astronauts and start overengineering everything. It can be useful if you’re working on a legacy codebase and need to understand the jargon that can appear in [possibly overengineered] existing codeb…

To all readers who've never experienced it, working on a large Java (and other) codebases where the original developers completely overused patterns, your life will be hell in my opinion, just as much as a codebase written totally without thought or patterns.

Patterns can be useful but only in moderation and only with reason. They're spice.

A contrived example, but:

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

FizzBuzz Enterprise Edition. It's enterprisey!

Re: Ask HN: How to transition from academic programming to software engineering?

#85

I have hired some PhDs in your situation and worked with others, I personally just went to work after I got my BSEE. My observation is that you're halfway there when you realize that you need to improve, of the folks I saw who did poorly it was because they didn't realize that you could be both the smartest person in the room and the least capable at the same time. Right now, on your first job experience, even a kid…

> read "The Design of the UNIX Operating System", read "TCP/IP Illustrated Volume 1"

What? Those are unnecessary details as far as software engineering is concerned.

Re: Ask HN: How to transition from academic programming to software engineering?

#86

I have hired some PhDs in your situation and worked with others, I personally just went to work after I got my BSEE. My observation is that you're halfway there when you realize that you need to improve, of the folks I saw who did poorly it was because they didn't realize that you could be both the smartest person in the room and the least capable at the same time. Right now, on your first job experience, even a kid…

> folks I saw who did poorly it was because they didn't realize that you could be both the smartest person in the room and the least capable at the same time Any advice to deal with this kind of people would be much appreciated. I had a hard time trying to convey basic software engineering practices such as not hard-coding file paths, using version control instead of filenames to manage versions, removing dead code,…

Sadly it is very much a person by person process. In my experience with folks like this there are people they can "hear" advice from and those that they cannot. One option is to talk to their original PhD adviser (if they are still around) and get them on board. You and the adviser's interests are aligned, you both want the person to succeed and to do so they have to be able to hear your guidance on how to be better at the job. Sometimes they will be able to hear it from someone they have already put in the 'trusted advice' category.

Re: Ask HN: How to transition from academic programming to software engineering?

#87

I have hired some PhDs in your situation and worked with others, I personally just went to work after I got my BSEE. My observation is that you're halfway there when you realize that you need to improve, of the folks I saw who did poorly it was because they didn't realize that you could be both the smartest person in the room and the least capable at the same time. Right now, on your first job experience, even a kid…

> read "The Design of the UNIX Operating System", read "TCP/IP Illustrated Volume 1" What? Those are unnecessary details as far as software engineering is concerned.

I would be interested to know why you think of them as unnecessary details.

What I like about them are that they describe large complex systems that have to work with a bunch of people plugging in their own implementation of the parts. For me, both books give a good sense of what you need to do to enable the product you are working on to evolve successfully, and highlight areas where a lack of flexibility impacted that evolution.

So often in programming you look at your code and have to evaluate not only what features you are delivering but also what paths you are closing off with your design. In my experience the folks who excel at programming hold both the model of the system in their mind while they execute some part of it.

I think both books give a flavor of that.

Re: Ask HN: How to transition from academic programming to software engineering?

#88

I have hired some PhDs in your situation and worked with others, I personally just went to work after I got my BSEE. My observation is that you're halfway there when you realize that you need to improve, of the folks I saw who did poorly it was because they didn't realize that you could be both the smartest person in the room and the least capable at the same time. Right now, on your first job experience, even a kid…

> folks I saw who did poorly it was because they didn't realize that you could be both the smartest person in the room and the least capable at the same time Any advice to deal with this kind of people would be much appreciated. I had a hard time trying to convey basic software engineering practices such as not hard-coding file paths, using version control instead of filenames to manage versions, removing dead code,…

If you have two such people, you might get there by making each of them the sole maintainer of the other's code. They might - might - see the problems when it's being done to them, instead of them doing it to others.

More in general, the problem is that these people have been in an environment where programs were small enough that those practices didn't cause problems. They've moved into an environment where the scale is different, and those practices now cause real pain. Until they experience the pain (rather than just being told about it), they aren't really going to get it.

Re: Ask HN: How to transition from academic programming to software engineering?

#89
post #54

Earlier quoted context omitted.

This is pretty good advice overall. One small change I suggest is to take it easy on Design Patterns and the like. I’ve seen people in OPs position (general smarts but limited production experience) turn into architecture astronauts and start overengineering everything. It can be useful if you’re working on a legacy codebase and need to understand the jargon that can appear in [possibly overengineered] existing codeb…

I've written software over a decade and I loath the design patterns book. I would not give it to a beginner as it would corrupt their mind with useless drivel . It's authors exhibit themselves as morons who celebrate renaming existing computer science concepts while occasionally mixing and matching them. I would not be this uncharitable towards it if it was not such a famous (and hence harmfull) book. It's harmfull b…

I disagree.

Design Patterns are very useful, but they are a tool like anything else.

They're not just a bunch of things with cutesy names, they are the most common and core patterns that we can use in OO.

Yes, they are way overused, particularly in Java, but they are useful.

The book could be summarized however.

Re: Ask HN: How to transition from academic programming to software engineering?

#90

I have hired some PhDs in your situation and worked with others, I personally just went to work after I got my BSEE. My observation is that you're halfway there when you realize that you need to improve, of the folks I saw who did poorly it was because they didn't realize that you could be both the smartest person in the room and the least capable at the same time. Right now, on your first job experience, even a kid…

> read "The Design of the UNIX Operating System", read "TCP/IP Illustrated Volume 1" What? Those are unnecessary details as far as software engineering is concerned.

I think you are interpreting "go read" as in go learn these by rote. He's not saying go memorize the details of these Unix and TCP books. He's saying go read them and absorb their gestalt approaches to decomposing complex systems so you can think about your own problems that way.

To this list, I would also suggest compiler construction or database systems as different topics exhibiting the same thing.

A more basic challenge for a scientific programmer might be absorbing the mindset of tool building rather than problem solving. It's a different mental perspective to think of your code as a product for other developers rather than as a means to producing a data artifact.

Post reply on HN