Personal Lessons from Growing as a Software Engineer

Below, I share some lessons I have learned as I have learned and grown in computer science and software engineering in general. I will (hopefully) add more as time goes on. I’m still very early on in my career, but I often take time to reflect. Hence these ‘lessons’.

Without further ado…

Programming Languages (and other technologies) are just tools

Some programmers tend to have strong opinions about certain languages or frameworks or whatever technology is available. I actually think this is okay–if you can put aside those opinions and work with a technology you don’t like if need be. I have learned to see these things simply as tools that are available to get a job done. If a certain programming language, for example, is the best for a certain kind of project, I should put aside my personal feelings and learn it so I can work with it. Unless I helped build a certain technology, I honestly see no reason to have any unreasonable attachment to it.
This belief of mine was tested when I began to work with Golang. Go is…an interesting language. Having worked mostly with Python that abstracts away a lot of things, it was a ‘pleasant’ surprise learning the underpinnings of Go. Take reading from a file for example. One (and probably not the shortest) way to read from a file using Go would be:

package main
import (
    "os"
    "fmt"
    "log"
    "bufio"
    "io"
)
            
func main() {
    f, err := os.Open("input.txt")
    if err != nil {
        log.Fatal("error opening file: ", err)
    }
    defer f.Close()
                
    fileReader := bufio.NewReader(f)
    for {
        line, readErr := fileReader.ReadString('\n')
        if readErr == io.EOF {
            fmt.Println("-------Finished reading file--------")
            os.Exit(0)
        }
        fmt.Println(line)
    }
}
            

as opposed to using Python:

with open("input.txt", "r") as inputFile:
    content = inputFile.readlines()  # reads the entire file line-by-line as a list into a variable. Not advisable for large files

for line in content:
    print(line.strip())

Having to learn about these things generally abstracted away by Python, like bufio and bytes wasn’t exactly something I’d expected, but Go is pretty good at doing what it was made for, so I had to use it. Go definitely helped change the way I think about programming as I began to embrace its syntax for what I needed to do.

The Engineer must wear many hats

I think this especially where tech profits. There are many different people with diverse experiences, and that diversity can lead to creativity.
Individually though, it helps to be a generalist in a sense; even if you specialise in a particular area, be flexible in what appeals to you. In day-to-day work, problems will arise that will require skills which may be outside your specialty–from management to development. To solve these problems, we’ll have to wear many hats.
I suppose part of the credit for my understanding of this goes to my first year coursework on the fundamentals of design thinking.🙂 University does help.

Mathematics is important

There will probably always be the debate of how much math is needed for computer science and software engineering in general. However, the impact of mathematics on computer science and software engineering is undeniable. Many things are direct derivatives of mathematics. In addition, I find that most innovators in this field are usually folks who have embraced mathematics–simply because it allows you to reason about your programs outside the context of code. A great example is Leslie Lamport. And not to mention proofs and how (in theory) no amount of testing may ever be enough validate an algorithm. You don’t have to be a whiz–I assure you I am not–but you definitely need a willingness to learn and apply it when necessary.

Always try to understand how the system works

‘System’ here can mean a lot of things to different types of software engineers. But the idea here to to strive to go deeper and understand how the tools you use work under the hood. Some ‘niche’ errors can only be solved by having an understanding of why something works the way it does, and this can set you apart. Besides, it is this understanding that will enable you to do technically innovative work a lot of times. The point is to understand deeply, because once we understand deeply, we understand quickly.
However, I’d also add that you could (should?) only try to understand the system (or parts of it) if you need to. This is because software systems in general have gotten really complex, and understanding the underpinnings of a system has become more difficult (and sometimes nearly impossible) for one individual especially if you didn’t create it.
As John Cormack said in this clip, “You can’t know everything, but you should convince yourself that you can know anything.”

---

That’s it for now! As mentioned earlier, I hope to update these lessons as time goes on. If you’re a software engineer or other professional, comment what lessons you’ve learned in your field!