Early April marks the first full year of my engineering career. Having already received my annual review, I decided to start this topic early. There are SO many fundamental skills that I’ve learned that I hadn’t picked up in school or any of my past engineering jobs, and I definitely want to share them out here in the open.
Lesson #1: Explaining Design
I’ve been learning that my main flaw is trying to both understand and explain software design beyond the surface level.
I don’t understand how people can just “get it” after being verbally told how an entire component works, talking about how individual classes’ instances are used and how it helps the system. I can understand them if they’re taken rather slowly, or if I’m given visuals with the explanation, but most people on my team just explain everything right there and then (given a 5-10 minute lecture) while the recipient seems to be able to instantly work off that. I personally have to read up documentation, step through the code, draw up block diagrams, etc. just to start working, which can take several hours. My results at least tend to somewhat make up for it at least.
Even after finished an entire component myself, I can’t seem to be able to explain it as effectively as I would like. I never really know how detailed I have to be when explaining. If it’s a high level, they don’t really get much out of it, at least in terms of being able to work with what I’ve said. The more detailed I go, the more I question myself while I’m explaining, do they know this? Do they know that?, and someone along the way gets confused in the ocean of details, possibly even myself. Even when I draw out diagrams while working on my part, I can’t use them to explain to others since they are drawn and written out at the lowest level specifically for my use, such as “This method Foo() calls this method Bar(), and in Bar() it uses this class Class, which uses ClassA, ClassB, ClassC…” The other guy doesn’t need to know all of that. But what exactly do they need? It’s difficult for me to determine all of this information, right in the moment of being asked for an explanation. If I’m given preparation to explain, such as a scheduled informal presentation, I’m fine. But right on the spot? That’s too much for my brain to process all at once. Pretending that this imaginary meeting will always happen? That’s also too taxing on my brain without having to worry about all my tasks on hand. There’s this fine line between chaos and structure that I have yet to find.
I’m working on it. It’s a constant trial-and-error process where I’m constantly analyzing the way people explain things to me as well how I can make immediate improvements. I’ve gone a long way from when I started, but I’m nowhere near where I would like to be just yet.
Lesson #2) Pick up Terminology ASAP
The fastest way to understand a project absolutely is understanding the terms being used. This has been my number one priority lately when I’m given a completely new feature to design. This is always something that an engineer will need to do as their new task requires a specific technology that has not yet been used in the project, particularly a new framework.
For example, the first framework I had been exposed to on this job was Windows Communication Foundation, or WCF. The architecture of the framework is shown below.
Not even having seen this diagram until I started writing this post, I’m verbally told about Data Contracts, Service Contracts, Policies, Bindings, Behaviors, etc. What is all that? What is even a contract? A binding? I ask these questions whenever I’m first introduced to them, but no matter how much they explain, I can’t understand it to the point of it helping me with my work, until I look up thorough definitions and examples online. It may even take me a few days or even a week or more of actually working with it, faking it until I make it, to truly digest each term and when to use it. Once I get to the “aha!” point of revelation, understanding comments and explanations from others becomes so much easier.
Lesson #3) Peer Reviews
Peer reviews are absolutely essential, but in our project group they’re treated rather casually. However, I learn a lot more from reviewing other people’s code compared to working on my own tasks and having people review mine. As a new grad, I always thought that I wasn’t high enough of a status to make bold comments, but it seems that the less I worry about that, the better the process goes for everyone. These goals are on my mind whenever I go through a peer review:
- I personally make sure that making my comments of high quality and value is a priority. If I don’t, the peer review is more of a time waster for everyone. What is quality, and what is value? It’s more than fixing typos, more than making the code cleaner just through white space. It’s not restricting myself to that one block of code, but also seeing how it fits within the system.
- I take the time to read through the entire class, not just the scope that the developer worked on. What if there’s an inconsistency between old but untouched code and the newly-updated code in another scope? What if I’m missing essential information by not reading the whole file?
- I ask how something works if it’s new to me. Even if there’s nothing wrong with the code per se based on my understanding from a quick Google search, I’ve been gaining a lot of knowledge, and sometimes even a new way of thinking, thanks to a simple question on a review. I’m hoping that the whole “teach to learn” concept benefits them as well.
Unfortunately, the rest of my team barring one or two people does the opposite of what I do, so I feel like I don’t learn much from reading their comments. It makes me feel like I’m just giving them extra work for no good reason, and because the code is not thoroughly reviewed, bugs come up later that definitely could have been prevented with a thorough review. My efforts in these reviews however definitely have not gone unnoticed; many peer evaluations have said that they love putting me on their review because of the above (in our team, each developer can arbitrarily decide who to put on each review). Even my supervisor had noticed and said this was a huge factor in my significant raise.
The one downside is that because of my perfectionist approach, one review could eat up as much as two hours of my day. But to me, it’s definitely worth it.
Lesson #4) Stick to the Process
Right now we just released the first of I believe four version of our product to the customer. Of course, that means we were behind and have a lot to catch up on. The overtime is real, and it’s definitely burning people out.
No matter how much of a time crunch you may or may not be in, don’t forgot the fundamentals of how you work. People are currently rushing on their work, skipping out on the unit tests, coding first before reaching out to the drawing board, etc. Bugs are more prominent, and people are even pushing in code that doesn’t even compile. I was required to stay late the last few nights before the deadline to fix plenty of bugs introduced by others’ new features, and most of the bugs could have been avoided through a unit test. Everyone should have a physical reminder at their desk, say a printout of a flowchart diagram or even a symbolic object like a rubber duck, no matter how much they believe they don’t need it. The fewer mental barriers, the better.
This is actually one of the biggest lessons I’ve learned from my art classes in college, and it truly applies to everywhere in life. Stick to the process. Don’t less stress take over your mind. It may be slower in the short-term, but it’s much faster in the long run.
Lesson #5) “You’re not thinking; you’re just being logical”
I forget how I heard about this quote by Niels Bohr, but when I heard about it sometime last summer, my mindset had turned a complete 180. Never had a quote clicked as hard as this one. To an extent, programming is easy because it’s logical. But oftentimes, there’s a hurdle that’s difficult for my team including myself to overcome: to engineer. And in some parts of engineering, you just have to stop thinking logically.
Logic is the reason why we tend to shut out ideas without even trying.
Logic is the reason why we can’t understand how to debug a problem (why does it only work sometimes?) and why we get mad at a solution that doesn’t make sense.
Logic is the reason why we can’t think about the user. About edge cases. About thinking outside the box.
If you can’t 100% prove that an idea isn’t going to work, just give it a chance. It might just be the solution you’ve been looking for.
Lesson #6) You can trust a new grad to work on a satellite project for an international government.
In the end, no matter how many years of experience in engineering we have, it turns out that we’re all pretty equal.
After anywhere from half a year to one year of full-time work, it doesn’t seem to matter. This seems to apply for any specific technology, any framework, any language, and even in general fundamentals.
Every project is a new set of problems that we need to solve. That’s what makes engineering a difficult yet fulfilling career. Whether it’s jumping between learning new frameworks or working on a dozen projects in embedded design, each problem is unique and we all have to struggle to get through solving them.
I constantly have to remind myself that we are all on an equal playing field, even matching my supervisor and project manager. If I don’t, I get intimidated. I become afraid of asking questions and offering suggestions, thinking that they’re dumb questions or answers. I keep thinking that I can eventually come up with the answer to my own questions without sounding dumb, or that I can see why my suggestion is absolutely and objectively, flat-out bad. I always try to think everything through before I ask or suggest, but if I’m intimidated, I may stay in that planning phase for too long. I won’t make as many risks. I’ll stay in my comfort zone. I won’t progress. See lesson 6.
In the end, my coworkers are often asking me these “dumb” questions. There are no dumb questions, but if they’re “dumb” in the sense that they didn’t even think about the question before asking, I don’t mind because it always reminds me about this even playing field that we share.
It’s especially relieving when I see people claiming they have been in the industry for one or even two decades, but my coworkers believe that my work has been more thought-out than theirs. Turns out you really can trust a new grad to work on a satellite project for an international government.
Lesson #7) “Stay hungry; stay foolish.”
Don’t settle. Don’t ever settle. Ever. Don’t. One of my biggest pet peeves I’ve realized is that way too many people get too comfortable. Not even Steve Jobs settled (owner of this quote). It kills passions and creativity.
During this past week, I’ve asked my coworkers, “How do you think we got so behind?” Most of them just said, “It’s just the way projects are; don’t expect them to ever finish on time. It’s unfortunate but we just have to accept those weeks.” Sometimes they gave an excuse saying something like “The manager didn’t take x into consideration,” which may be objectively true, but they’ve still let it sound like there was nothing they could do to improve their own situation.
It may be hard to not settle when you’re already making a guaranteed six-figure income no matter how hard you work, as long as you show up and don’t lose your job. Don’t let that affect how you think.
This applies to everything outside of engineering as well. The most beautiful thing about life in my opinion is constantly staying curious, opening your mind to everything the universe has to offer. Don’t ever stay in your comfort zone. Don’t ever settle.
Hope engineers and developers of all ages can gain from this post. I may still just be starting out, but I’ve learned so much throughout this past year, and I can only grow from here!