Lessons I've learned as a Software Engineer
“Recipes tell you nothing. Learning techniques is the key.”
— Tom Colicchio
As a SWE, you learn alot of lessons on how to write code. Lessons like cleanliness, modularity, and scalability, etc. But as a "great" SWE, you need skills other than just code writing skill. This post, hopefully, will give some insight in some things I've learned that isn't related to code.
Breaking things down into very basic levels:
We have shortcuts that we do everyday in life. There are a lot of things that we know so well, that we know it as truth, we kind of "take it for granted". Or some things that are so obvious, we expect people to know it. But in coding or teaching someone whose never seen it before, it's necessary to skip those shortcuts and break everything down to the most basic, fundamental levels. I'm aware that what I said might've been fairly confusing, but hopefully this example will clarify what I mean.
If I were to ask any random person on the street to list off the steps for you to get cash from an ATM, the list might look a little something like this:
1. Put debit card into ATM
2. Enter PIN
3. Choose dollar amount
4. Receive cash
5. Remove card
Here, we're taking alot of things for granted. Things that are obvious to anyone whose used an ATM before, but might seem extremely vague and confusing to anyone who hasn't used (or doesn't know) what an ATM machine is.
Let's try to write another list trying to teach someone who has never used an ATM before to withdraw cash.
1. Get the debit card you want to use.
2. Put the debit card into the slot on the ATM that says \"Insert Card\", making sure the correct direction is facing forward and up. The card will be held by the ATM for the duration of the
3. Use the number pad to input the correct PIN number associated with the debit card you used. Hit Enter after PIN number is entered.
4. Select the Withdraw Cash button on the touchscreen. (Yes, you can touch it!)
5. Select which bank account you'd like to withdraw the money from.
6. Select the amount of cash you'd like to withdraw (in multiples of $20). (Make sure you have enough in your bank account to cover the withdrawal, or it will charge you a fee).
7. Select your receipt option choice: Paper, Email, Text, or No Receipt.
8. After confirming the account, the amount, and your receipt choice, select Confirm on the bottom right.
9. Wait a few seconds for the ATM to process the transaction.
10. Retrieve your ATM card in the same slot you first put it in and put it away.
11. Retrieve the receipt from the receipt slot.
12. Remove the cash from the cash dispense slot.
Compare the differences between the first list and the second list. The second one explicitly states all the steps to use the ATM machine that the first skims over because of its obviousness or straightforwardness.
This "form" of communication is how we communicate to computers. Computers are dumb, they don't have any extra information that we don't give them. We have to explicitly state everything we want it to do.
This "form" of communication is also very helpful for understanding concepts/situations and how you can adequately teach someone the basics of something by breaking it down into little pieces for them to understand.
Autonomy
One of the most important things an engineer can learn is autonomy. Being autonomous is someone who can do and figure things out themselves. I see it as needing to get a task you don't know how to do done, and getting it done without asking for someone's help.
I know some people who, when needed to do something new, always ask for help first before even thinking about the problem myself. One example of this was installing Skype on the computer. We were playing a video game and team communication was important there. I told him to install Skype on his computer and he said he didn't know how. I proceeded to link him to the Skype download link. Through every step of the way, it felt like he needed someone to hold his hand through the process. Even though there were step by step instructions on the installer. As a friend, I don't mind helping, but there comes a point where you don't need me to tell you to hit the "next" button on the installer.
This applies for growth as an engineer as well. If your boss says to "add a new button on the page in React"; you're not going to ask him to hold your hand all the way through, even if you don't know how to do it right? You might ask him some clarifying things like, where to put the button, what color, etc. But in terms of how to do it, googling it would probably be the first step.
Being autonomous is different than being prideful. If you're genuinely stuck and need a little push towards the right direction, you should seek help. But if you're too proud to ask for help (because you're afraid of people judging you or whatever) that would probably cause more harm than growth. Typically, the hardest part to do any new task is just to get started. Oftentimes for me, I just don't know where to start or how I can get started. But with the first initial push, finding resources for the next steps are doable.
I see this type of autonomy useful for growth in a personal level also. Whenever I need to approach a new skill or task that I need to complete, personally, I feel that I don't want to hassle or bug any of my friends. I'll try and figure it out and get it done by myself. If I genuinely am stuck, I'll seek some help or advice from someone I can trust who has done or knows something of that task. But for the most part, I'll try to get it done myself first. I feel like the internet is too vast/wide for the internet to not have covered some everyday problem. (Sure, edge cases/outliers exist, but anything ranging from "how do I make a PB&J sandwich" to "what the routing number for XYZ bank" to "how do I make a new React component" should be covered by Google.