Category Archives: Career

Personal projects are like free weights

I thought of this 7 years ago and I still think it rings true. In my experience, school projects were tightly scoped and had things like a basic build system and boilerplate runnable code (e.g. main) already provided. Maybe even some tests. It trains a specific muscle in a certain way.

With personal projects, you do all of this yourself and incidentally also train the equivalent “stabilizer” muscles. Things like: making the repo, writing the main and boilerplate code, setting up unit tests, setting up CI, setting up dependencies and their management.

And in my experience, it’s all these “stabilizer” activities that define what it means to be a senior engineer. Junior engineers work within an existing project; senior engineers own the entire thing, including these “little” (critical) parts.

The point here isn’t to necessarily criticize CS education; there are good, practical reasons for setting up such project structure to ensure all students have a good experience, given the time constraints. The point is that students should be wary of not doing any personal projects at all throughout a CS education. Maybe it would be possible so students don’t have to do this in their free time, and build it into some kind of flexible course. I suppose this is the point of final capstone projects, but I think senior year is far too late to be doing this for the first time.

The difference between computer science and computer engineering

I first wondered this question as a confused 17 year-old, considering options for university โ€” this blog post is for that kid and people like him. It’s my opinion on this after working professionally in both fields and earning a degree in one them (CE).

I think tracing each back to its roots is a good way to gain an intuition for the difference. Computer Science is ultimately derived from Mathematics, while Computer Engineering derives from Electrical Engineering.

The boundary is blurry, but CS is classically more concerned with topics like algorithms & runtime (“Big O”), data structures, and the theory of computation (“What kinds of problems can we solve with computers, what kinds can’t we?”). You’ll do many more formal proofs in CS.

CE concerns itself more with how digital computing systems work in the real world, starting from foundations in electronics (i.e. transistors), to digital logic, building up towards embedded systems, the hardware-software interface, and computer architecture. The latter is where things get blurry and bridge to the “lower levels” of CS.

In practice, most practitioners of either have some awareness of the other, although I suspect (without evidence) that CE’s tend to know more about CS than vice-versa, on average. However I also expect that CE’s tend to write “worse” code than CS’s, on average โ€” “writing good code” and “knowing CS” do not necessarily correlate. 1

So which should one choose?

I can only offer this scattered set of anecdotes and advice:

  • I knew many more CE majors that switched to CS, than the other way around. (Mostly people that just wanted to become “programmers” and realized that circuits & electronics are not for them. I’m not sure if they enjoyed the theory courses more, though.)
  • I have heard and personally agree that it’s easier to go “up” the stack than “down”.
  • Don’t give any experience building computers or doing IT support too much weight in the decision โ€” those topics are neither CE nor CS and rather fall into the field of “IT” which is largely separate. You might be surprised how possible it is to study either CE or CS, work in these areas professionally, and not know how to physically build a computer. But in general, building a computer falls closer to CE than CS โ€” but you will be learning how to design (some of, at a very high level) these lego pieces you are putting together.
  • Personally I’ve always been foremost curious “how computers actually work” and CE has served me well.

Lastly, what about “software engineering?”

Software engineering is an even newer field, derived from Computer Science, but describes the job descriptions of many (if not most) people that study either CS or CE. My view of it is that a degree in it focuses on the most practical elements of CS, focusing less (or not at all) on the theory. I don’t expect much of CE is covered it in, except for maybe a cursory overview of digital logic and computer architecture. But frankly, I don’t know any software engineering majors and am not qualified to really speak on this.

How did you choose between them?

Not rigorously. My decision was mostly based on the presence of other “engineers” in my life and a friend that studied CE. These were not good rationale for the decision, but I lucked out and had a good outcome anyway. I think I would have been fine either way, and naturally gravitated up or down the stack to the point I’m at now. Being CE did allow me to take some very cool classes in college like a very modern, practical compilers course using LLVM (unlike the more theory based compilers course taught in the CS school) (which had a direct impact on my ability to get a great job after) and a fun embedded systems class.

Sometimes, you just need to be willing

Sometimes, you just need to be willing. No special skills or particular competence necessary โ€” simply just being willing to do something others can but won’t do.

I learned and have profited from this realization at work in the past year. A certain set of important tasks on my team are somewhat hands-on in nature and not compatible with remote work. Our colleague that usually does these left the team. I stepped up and filled this gap.

The work is not particularly difficult โ€” my teammates are smarter than me and could surely do it also. But I’m the only one that was willing and able to sacrifice remote work and commute every day. So I’ve been doing it.

Although it’s not the hardest, the work is nonetheless very important โ€” critical, even. So I’ve been getting a lot of credit, brownie points, and even a raise from doing it.

Not because I’m smart โ€” just willing.

Learning on your own pales compared to spending time with experts

This has become crystal clear to me at my current job. As much as I’ve had success teaching myself things about computers, nothing, nothing, beats spending time with experts and learning from them.

I had never truly experienced this before and was shocked at how much I was able to learn, in such little time โ€” about C++, git, Linux, and more.

It can be a significant price to pay, but nothing beats literally becoming an employee at a company with experts in a field you care about and joining their team. This is ideal from a learning perspective because as a team member, the experts become invested in your growth and are incentivized to transfer knowledge to you. You just need to be ready to receive it.

Once you’ve tasted this, this truth is also bittersweet. You can only work at so many places. If you have many interests, you now have to live with the fact that for most areas, your learning will be stunted relative to what it could be.

My deep gratitude to the experts in my life: STK, DIR, CSK, MKL, RYB, MZA โ€” thank you.

Why you feel stupider than ever, despite being smarter than ever

I’m 10 years into my tech career and yet I constantly feel so, so stupid.

It’s entirely self-originating; not because others are mean to me. (Ok maybe partly also because I’m lucky to be around smart people).

Why do I feel this way, despite mountains of evidence to the contrary โ€” that I’m not stupid, and know a thing or two about what I’m talking about? Is my self esteem really that bad?

I think it’s also because I’ve been learning so much. The more I learn, I more I realize I don’t know. And I posit that the weight of a known unknown feels disproportionately bad to the relief of converting it to known known.

So, the equation looks like:

All Knowns = Known Knowns + Known Unknowns

Perception Of Intelligence = Known Knowns / All Knowns

(Smaller = Less Intelligence = More Stupid)

This makes sense to me. I think I accumulate known unknowns at 10x the rate of known knowns โ€” it takes so much more energy to learn something, than to learn merely of the existence of something.

Everyone’s career sounds more impressive than yours

This is something I’ve observed ever since I started working. Everyone else’s job always sounds way more interesting, technical, or impactful than mine.

For example, when I worked at Trail of Bits, I spent years working on a research project for automatically finding crashes in computer programs using a technique called symbolic execution. Sounds hard! Oh, and the technique is designed for programs where you don’t have source code (sounds extra hard!).

In many ways the job was cool, hard, and technical but what was really uninspiring was that 1. the tool wasn’t actually that effective and 2. we didn’t have any users (probably because of #1). As my colleague Yan once joked, it sometimes felt like we were working on a “Fisher-Price Symbolic Executor”. I often felt like an imposter “playing” software engineer/researcher.

When I visited my old colleagues at Drift, who were working on a web product with thousands of users, I felt inferior. It seemed like they were all working on such impactful and real-world problems. Maybe it wasn’t quite as “novel” as what I was doing but it sounded pretty technical and not easy to me!

However, the way they introduced me to other colleagues that didn’t know me was “This is Mark, he’s moved on and now works on the real hard stuff.” I can only speculate that they felt the same thing that I was feeling. From their perspective, I was working on a super hard, technical, sexy research problem โ€” unlike their boring, run of the mill web app.

This has happened more times than I can count in all sorts of settings, especially conferences, where you’re meeting a lot of strangers who all seem to be smarter than you and do very impressive things at highly functional organizations. (Unlike stupid me, doing unimportant stuff at the dysfunctional dumpster fire of a company I work for!)

The point is familiarity breeds contempt. Being so close to your work dulls the good parts and makes the bad parts stand out sharply in relief. Chances are if you joined their team or organization you wouldn’t find it as rosy as you picture it now.

Dimensions of job happiness

I reflected on the qualities of a job that matter to me and here’s what I could come up with:

  • Technical intensity
  • Personal interest in the domain
  • “Sexiness” of the domain / Can laypeople understand it? (Or better yet, find it intriguing?)
  • Deploy at “scale” (leverage/power) (>= 1000 users)
  • Brand recognition & enthusiasm

These build on top of some base requirements of: working with nice & smart people that I enjoy being around, and being a good fit with the overall company future.

Software engineers must learn to write

There is an immense amount of written communication involved in a programming job:

  • Commit messages
  • Bug reports & debugging discussions
  • Design documents
  • User documentation
  • Project documentation, READMEs, internal dev documentation
  • Project announcements
  • Comments & in-code documentation
  • Making complex situations simple for stakeholders
  • Handling support tickets
  • Mailing list discussions

Software engineers must learn to write well in the same way that they should also learn how to stay organized โ€” they avoid doing so to their own detriment.

Do you need to learn how to implement a red-black tree?

How to not feel dumb around “smart” programmers

When going to programming meetups, conferences, or starting a new job, it can be extremely easy to feel dumb around other engineers there. Sometimes these engineers truly are geniuses, but many times they’re not as “smart” as your immediate imposter syndrome is leading you to believe.

My advice, especially for beginners, is to remember that these people are probably talking about a domain they are extremely familiar with, and have spent probably 1000x the time with than you. You probably have stumbled upon to a topic that they are specifically knowledgeable about, which gives the impression that they’re ultra smart (and you’re ultra dumb, for not knowing anything about it).

The key is to remember that this impressive depth of knowledge is likely limited in breadth. If you were talking about your domain, you’d might know a lot more than them.

It’s also easy to feel dumb when watching a conference talk. My trick here is to remember that the reason this person can speak so confidently about such a technical topic is because, again, they’ve spent 1000x more time on it than you have. They’re had their face pressed directly against this problem for a long time, which is why they know all this and can talk about it.

This comes from my experience:

  • Entering the programming world (feeling dumb at hacker club in college)
  • Enter the infosec world (feeling dumb at infosec conferences)
  • Going to conferences not directly in my expertise (i.e. the LLVM Dev Mtg)
  • Entering the audio programming world (feeling dumb at audio conferences)
  • Feeling dumb in many, many conference talks