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

whenever you want or need to do something more than shuffling bits between buckets with different names, do some research. most likely someone already did it and published a library for it.

test third-party libraries. it's uncommon to find bugs, but it's not so rare that it happens only to others.

don't forget to leave comments. a lot of my code review questions could be answered (hence could be not asked in the first place) by a well placed comment.

sometimes people say that code is documentation or code should read like documentation. this is false. code can explain (usually poorly) what it does but it can't give a rationale why it does it the way it's been written, can't say what it doesn't do, etc. always write some documentation - comments and commit messages at least. this should be enforced in code review.

i'd say engineering is about not writing code unless absolutely necessary. code is an asset, but it's also a liability. you really don't want more than you need.

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 who never went to college is better at programming than you are because they've been experiencing all the pitfalls that can happen and have built up a knowledge from that which is perhaps more intuitive than formal but serves them well. What you have over that person is that you've trained yourself to consume, classify, organize, and distill massive amounts of information in a short amount of time.

Use that training to consume everything you can on the art of writing programs. Read "Test Driven Development" read "Code Complete", read "Design Patterns", read "The Design of the UNIX Operating System", read "TCP/IP Illustrated Volume 1", and a book or two on databases. With your training you should be able to skim through those to identify the various "tricky bits" and get a feel for what is and what is not important in this new field of yours.

Soak in as much as you can and ask a lot of questions. Pretty soon no one will know you haven't been doing this your whole life.

Here are some principles that inform my taste in maintainable code:

- Each function should do just one thing.

- Don't reuse a variable if making a new variable with a new name would describe the value better.

- Give functions verb names that describe what they do. If that's hard, they may be doing too many things.

- A function should either change something or return a value (command-query separation)

- Any data should have a single, canonical source of truth. https://en.wikipedia.org/wiki/Single_source_of_truth

- When deciding between making code DRY https://en.wikipedia.org/wiki/Don%27t_repeat_yourself or not, decide if future changes should affect both places at the same time (use DRY) or not (probably doesn't need DRY, maybe shouldn't have it.)

- Avoid spooky action at a distance https://en.wikipedia.org/wiki/Action_at_a_distance_(computer... and if you can't, refactor or at least add comments.

- Write modular functions that can be used without understanding much about the function beside what the name/arguments tell you.

One measure of your success in this area is how quickly someone who'd never seen your code could describe what it does.

Does your institution have a Research Software Engineering group? I think increasingly universities acknowledge the gap between how academics use software and how industry approaches it, and I think that would be a fantastic first step if you were looking for a change.

https://rse.ac.uk/

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