Advice for Students and New Grads from a Senior Software Engineer

I recently asked a senior software engineer, the founder and creator of em, for advice on starting out in my career. Her insights were too valuable not to share, so I've compiled them here:

• Learn functional programming. It will make you a better programmer. Period. I recommend Scheme, PureScript, or Elm. I also recommend Structure and Interpretation of Computer Programs by Harold Abelson and Gerald Jay Sussman. It is a classic CS text that I had in undergrad. I only worked through a small amount of it, but it really challenged me to see programming differently.
  • You may never build a large project in a purely functional programming language, but note that almost all languages these days have functional and object-oriented mechanisms that you get to choose from. Almost every week I get Javascript/Typescript submissions from developers where they use unnecessary mutations and state that increases complexity and decreases readability. This is a direct product of them not being able to "see" how to do things without side effects. At minimum, you should get really comfortable transforming data with map, filter, and reduce.
• Learn some DevOps skills, as they will be valuable in many different software development roles.
  • Q: I've been working with AWS for a few years now. I was planning on studying for an AWS solutions architect certification in school, but never got to it. Would you recommend getting a certification? Is it worth the time spent studying for it?
  • A: In general I think certifications are not worth it in this field. People are just happy to know you have the skills, and you can learn everything online. If you have an employer that is asking for a specific certificate, then consider it.
• Learn and practice encapsulation, coupling, and separation of concerns. In my experience, this the biggest thing that separates junior devs from mid-level devs (or mid-level from senior). The best developers understand how to minimize complexity, hide implementation details, and create loose coupling in the right places to allow modification.
  • Q: I'll start reading more on encapsulation, coupling and separation of concerns, too. Do you have suggestions on how to get better at this? Are there any talks or articles in particular that have changed how you view these? In an attempt to write cleaner code, I’ve watched various videos on design principles in university, but I've had a difficult time actually applying them, especially outside of OOP.
  • A: I'm afraid I don't have any specific resources. Design Patterns: Elements of Reusable Object-Oriented Software is the classic text, but you're right that it's more geared towards strict OOP environments like Java. I think there must be some newer resources out there, I'm just not familiar with them!
• Get experience both freelancing, working for a startup, and working for medium-large companies where you have to interact with other internal teams. These experiences will help you understand flows of communication, client demands, product design, and project management at a deeper level.
• Consider specializing in an in-demand technology that you are interested in, e.g. AI, blockchain, native apps. There are more opportunities and quicker advancement in areas where there is high demand.
• There are many ways to do the same thing in programming, but for a given project or set of constraints there is always one best way. It's often elusive. I rarely nail it, and I always see my mistakes in hindsight. But it exists. Developers that forget that tend to plateau pretty quickly.
  • Q: When you say that you always see your mistakes in hindsight, I was wondering how you spot it. Being able to spot these is the prerequisite for improving, but it's often hard to see where exactly I went wrong or how I could do differently next time, even while I'm refactoring.
  • A: Yeah, it's never 100% clear. You have to develop an intuitive sense for it. Often you'll have a lingering suspicion that something could be done better/cleaner, but you won't know how. Then a year later you will encounter a similar problem and suddenly see a better way! That's how it goes. You develop a feeling sense for good/bad code with experience. You learn to recognize code smells: https://refactoring.guru/refactoring/smells. Software engineering is luckily very merit-based, so if you can demonstrate your technical competence and ability to deliver solutions, you will be valuable to many teams!