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

It is critical for a company to have a concrete on-boarding process. If your present company doesn't have a good one take this as an opportunity to design one. You will learn a lot and also help others in the process.

Here are some of the guidelines:

  # Code style/guidelines
  # Git/version control workflow
  # Testing methodologies & tools used
  # Agile/project management tools used and best practices
  # Read the wiki about infra/services used in production/dev/staging and its workflow
  # Release guidelines & workflow
  # Mentoring process
  # Engineering style/culture

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 because software engineering is really hard, and they just add up to the load by trying to have the reader memoize their junk instead of doing something that would actually make them a better programmer. And, if you try to use their concepts while programming - shudders, oh god help you.

I'm not going to iterate over every pattern. Here's an example:

Flywheight? You assholes, just tell memoization for what it is. Why don't you rename existing data structures as well? Good thing those come out of the box, otherwise you would have began the book by renaming array, linked list and dictionary. Maybe you would have called linked list "the chaingang" or something.

You don't simplify things by giving things cuddlier names. You stunt peoples growth that way.

Gang of four book is a malignant offshoot of the practice of attempting to make software engineering better by legalizing and dogmatizing it by decomposition into trivial details that hurt your brain. It's a branch of 'consultancy driven software development' where people attempt to aquire a halo of professionalism by calling things by fancy names and over-complex descriptions (while skipping the practical things with equally complex names but at least those weren't made up by a bunch of idiots).

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

I read systems science at university. While we did some technical stuff like basic Java programming and database design, we mostly focused on WHAT a system is and how to design one from certain requirements. So when I got my first job, as a web developer, I hit the ground quite hard. I hadn't really programmed in my spare time either so I didn't have that backbone experience. (You might wonder why I got hired in the first place, in hindsight, I also do).

Nowadays, some X years later, I identify myself as a backend developer and I tend to stay out of those "up in the cloud" discussions about what a system should look like. So how did I get here? First of all, I think I was pretty lucky having a boss at my first job who wasn't interested in me being really productive during my first time there, but rather wanted me to learn and grow with the company. I also had great colleagues, especially my then team lead, who really took the time and showed me the ropes so to speak. I bought one book, which I didn't really read. I did some online classes, but I mostly learned programming, problem solving, TDD, etc. by working.

I've worked in a variety of companies as employee and consultant and I have some counterintuitive advice that applies to building things on the web: In almost all cases, things like code maintainability, coding "standards", and TDD, go out the window during actual development. I'm not saying this is good, just that it happens (this is more a management problem than a software development one). There are deadlines to meet, changes to make, surprise features to add, etc. And usually you're just throwing things away and building new things before any of this comes back to bite you. Being able to go with the flow and handle chaos --flexibility-- is probably the most important skill to have. The job ends up being a lot of communication. If you're lucky, you'll get to code some cool stuff. But you'll also have to hardcode something clunky and ugly because there was no time to do it right. Be OK with that.