Live data from Hacker News

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

news.ycombinator.com

71–80 of 105 posts

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

#71

Some general advice I've given multiple junior developers over the years, you probably aren't a junior but most likely applicable to the advice you are seeking. These were passed down to me by other developers. Other HN folk will have links to literature but hopefully my advice will give you a precursor. * testing - write your functions small enough to be readable, but not so small their abstractions are meaningless…

> write your functions small enough to be readable, but not so small their abstractions are meaningless

More precisely, you want your functions to be deep. The interface to implementation ratio must be as low as is reasonable: you want to hide implementation behind interfaces that are much smaller than them.

This goes for functions (something with 5 arguments that takes 2 lines is too shallow, something with 2 arguments that spans 20 lines is deep), classes (something that is mostly getters and setters is too shalow, something with 3 methods full of business logic is deep), or anything else.

This is not just for testing, this is to make sure you can understand the program at all. Deep functions (and deep classes, and deep modules…), are also about good old decoupling: the less you have to understand about a piece of code to be able to use it, the better.

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

#72
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…

While I agree that the GoF book is way overrated, I think you're being a bit harsh. Most of the patterns are actually tricks to overcome limitations of statically-typed class-based languages like C++ and Java. They can be useful in these languages but are not necessary with dynamic languages. Take Strategy for instance, with Python or JS, we'd just use a callback but in old Java you couldn't do that, hence the need f…

I wasn't harsh yet. While prompted by your comment, below I'm not directing any of this towards you but GoF book the icon. Excuse the rant.

"Composite, Command and of course Observer"

Each of which is trivially obvious way to structure your program when that need arises. You said it the best - GoF tried to attack a very real problem - the unwieldiness of C++ and Java - but they did really not come up with any actual solutions. And they extend this non-value-adding gibberish into a tome, that somehow has become a cultural icon of some sort.

The basic premise of the book is this: "We looked out how people use object oriented languages and found this and this and this". Congratulations. By that approach they've enumerated a bunch of gobbledygook. They've not invented anything new. Nor have they done any deep analysis of the fundamental underlying concepts, and by their chosen approach I'm taking a guess they would lack the capacity to add anything of value to that discussion if they tried. Which is totally ok, most people, like me, are mediocrities.

Reading gang of four is painfull, because it reads like the work of a very clever first year CS student who is over eager to create contrived examples of these nuggets of things he has discovered among the work of his fellow first year CS students. Without actually bothering to do a literature survey, or - most critically writing any massive programs or doing any complex abstract work of any worth.

In other words, it reads like it was written by a clever, verbose, and over-eager novice.

As an excuse, it was written in the dark ages in the 90's - a period of large scale communal lobotomization and attempts to forget the lessons of history. As such I would not judge it too harshly, if not for the fact that people keep bringing it up as some sort of book of actual wisdom like Structure and Interpretation of Computer Programs - which it really, really, really is not.

The last reason why I don't like GoF book:

In their title they steal Christopher Alexander's notion of Pattern Language in architecture, and totally and completely misapproriate it. Christopher Alexander's books are totally awesome. "Notes on the Synthesis of Form" and "Timeless way of building" are really beautiful books for anyone to read who has to design complex systems.

Christopher Alexander's patterns are not piecemeal lego parts you can put together - they describe parts of a whole and each pattern is a composition of elements that - and this is the key part - fits to it's surroundings and the design constraints of the original problem to be solved.

Gof book is borderline clueless, it confuses people, and it mis-introduced a totally awesome concept from another domain, thus effectively squatting on the concept and hindering any attempts to use those concepts in discussion of systems design since when you say "patterns" in CS context people automatically context switch to the GoF bastardized definition of the concept.

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

#73
A bunch of comments on this post give pretty good advice about what to expect, and if you're in your first commercial job it's probably worth going with the flow. However, one thing I'll add is that it's worth watching out for the "academic bad, commercial practices good" mindset. Keep your eyes open, form your own opinions about what is and isn't working. Don't necessarily kick up a fuss about the things you don't like right now but do file them away for the future.

https://yosefk.com/blog/why-bad-scientific-code-beats-code-f... is an interesting counter-point to some of the usual commercial-vs-academic thinking.

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

#74
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…

I wrote a long rant as a response to another comment above. To quote myself:

"It reads like it was written by a clever, verbose, and 'over-eager novice."

Design patterns are a really usefull concept. The GoF book just totally botches up that concept by dwelving deep in trivial language details while missing the big picture.

Christopher Alexander's "A timeless way of building", and "Notes on the Synthesis of Form" are the books in architecture that prompted a lot of dicussion in software design circles, and from which I presume GoF got their idea of software design patterns.

What are good design patterns in software? IMO they are composed from the programming models exposed in a basic CS book like Aho and Ullman's "Foundations of Computer Science" and further developed in a books like Structure And Intrepretation of Computer Programs.

GoF is an ok anecdotal reference after those, but it really is not suitable as a didactic resource.

Peter Norvig wryly commented that 16 of the 23 pattern are either invisible or non-existent in lisp Lisp[0].

[0] http://www.norvig.com/design-patterns/design-patterns.pdf

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

#75

Some general advice I've given multiple junior developers over the years, you probably aren't a junior but most likely applicable to the advice you are seeking. These were passed down to me by other developers. Other HN folk will have links to literature but hopefully my advice will give you a precursor. * testing - write your functions small enough to be readable, but not so small their abstractions are meaningless…

I quite like this short piece as a way to explain why things like exiting early and not nesting loops are important: https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea...

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

#76

Thanks everyone, the comments are much appreciated. Here's a list of books and other media resources recommended so far in the thread: Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma... Vaughn Vernon, various: https://vaughnvernon.co/?page_id=168 Steve McConnell, Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2 Clean coder: https://cleancoders…

I'd like to re-emphasise sanderjd's point not to focus too much on reading books. I myself went from doing a PhD and a lectureship in mathematics (with some coding here and there) to a decent software engineering job in a smallish company. I've learnt everything on the fly by reading code, searching stack overflow, trying stuff out and coding alongside others. The great thing coming out of a PhD is not just that you have to be pretty smart to have done it: you now know you can grasp almost any aspect of human knowledge with sufficient brain racking. This is a vastly underrated piece of self-awareness which enables one to stay humble and tenacious.

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

#77
"Software Engineering" is merely a collection of principles, techniques, heuristics, structure and practice all validated by trial and error. As such you have to read a variety of books to get the overall picture. Specifically books with sizable code for various problems. You may find the following helpful to get started (many of these can be bought used and cheap);

* Fundamentals of Software Engineering by Ghezzi, Jazayeri and Mandrioli

* The Practice of Programming by Kernighan & Pike.

* Code Complete by Steve Mcconnell.

* The Unix Programming Environment by Kernighan & Pike

* Advanced Unix Programming by Marc Rochkind.

* C Interfaces and Implementation by David Hanson.

* Large Scale C++ design by John Lakos

* Unix Network Programming by Richard Stevens.

The key is that while reading the above you need to "get" how the code is "structured" rather than the details. For example, how does the code for a TCP server and client "look like"? It is a kind of spatial knowledge which you can then consider as one "module" of functionality and reproduce as needed. Large Systems consist of a bunch of layered and well partitioned modules exposing simple and clean interfaces. There will also be modules which cross-cut all the functional modules like "Error-Handling", "Logging" etc. This is the core of "Software Engineering", everything else is details.

Finally, you would also need to read a book/source where you can see all of the above principles put into practice while building a non-trivial (initially not overly complex) system.

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

#78
post #30

First of all, SW engineering is a practice with a lot of responsibility. The main responsibility lays in writing code, that is easy to understand. For example, if you think you write well written code, then try reading code that you have written a couple of months ago. Usually, a very painful experience :D So try to write code for an audience. This has been the trigger for me. Also I encourage code reviews and TDD. T…

I can vouch for Clean Coder. We watched them in our company. It's a small dev team so we took the time together. Afterwards we implemented a 4-line rule amongst other things. We don't always hold ourselves to it, sometimes 5-6 line functions make sense, but we strive toward 4. Sometimes it's as easy as breaking code out into a new function, but sometimes you just simply have to create a class for it. That way a lot o…

And this is why I don't like the clean code series and usually recommend against reading it.

Limiting function length to < 10 lines is like limiting your walking stride to 30cm. You'll spend most of your time chasing useless functions when trying to understand the system.

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

#79

Thanks everyone, the comments are much appreciated. Here's a list of books and other media resources recommended so far in the thread: Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma... Vaughn Vernon, various: https://vaughnvernon.co/?page_id=168 Steve McConnell, Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2 Clean coder: https://cleancoders…

Skip anything by Robert Martin (clean coder series) and read at first Ousterhout and then McConnell instead.

Martin is well intentioned, but very dogmatic about some things like TDD, functions size, personal responsibility, etc. You need to already have some decent engineering experience to be able to detect and ignore the harmful stuff from his books.

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

#80
post #56

Earlier quoted context omitted.

There are a lot of good recommendations here, and I certainly relate to the instinct to go to books when you're looking to level up a skill set, but I really think what you need is not a bunch of books to read, but a few people to watch do the work. The only real way to do that is to get a job alongside them. You can read the books at the same time; you can ask your new coworkers which recommendations they agree with…

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.

Post reply on HN