Photo by Jamie Street on Unsplash
January was my first month in my new job, and it has been going well :)
I've fixed a couple of bugs and been part of a small team to design the first draft of a new feature.
I'm looking forward to contributing more and also hoping one day becoming the ping-pong champion of the office.
- You don't actually know everything
- You will not get as much help as you need
- Tech is only half the battle; soft skills do matter
- You don't need to reinvent the wheel to make a difference
- You may not end up at Google or Facebook
- You won't understand everything you're doing
- Your evaluative metrics have shifted
- Master Your Tools
- Learn Every Day
- Improve Your Writing
- Unblock Yourself
- Own Your Projects
- You're Running a Business
- You're a Professional
- Done is Better Than Perfect
- Expect Change
- Learn When to Say No
There are a lot of things one can do wrong when approaching embedded programming from a pure software programming standpoint.
But here are the things that helped me not produce as much magic smoke as I used to:
- Read your specification
- Read the right specification
- Check connections thoroughly
- Plan your stuff
- Split your hardware into parts
- Don't hardwire everything
- Prototype and test on breadboard
- Ever heard of fuses?
- Figure out your audience
- Choose an interesting topic
- Read for inspiration
- Decide the length of your post
- Develop a content structure
- Write shorter sentences for skim readers
- Practice makes perfect
- Chase a career, not a job
- Personal projects
- Coding is the fun part
- People are unpredictable
- The illusion of easy money
- I am better then I think I am
- I'm not as good as I think I am
- Trust people
- Learning and development opportunities
- People don't leave organizations. They leave managers
- Teach others what you know
- My smile, still, stays on
- Don't hide your mistakes
- Process, Process, Process
- Stay committed
- Stay motivated
- Ability to influence and persuade
- Don't silo people based on their skillset
- Embrace cross-functional teams
- Explain alternatives and choose the best solution together
- Learning is Frustration
- How Do You Change Your Beliefs About Learning?
- Dive Straight In
- Avoid Comparison
- Embrace the Frustration
- Containers (Docker and Kubernetes)
- Cloud Platform (AWS, GCP, or Azure)
- Data Structure and Algorithm
- A Version Control Tool (Git)
- One Text Editors (VIM)
- IDEs (VSCode or IntelliJIDEA)
- Database and SQL
- UNIX (Linux)
- An OOP Programming language (C++, Java or Python)
- Networking basics
- One Scripting language
I realized that there was somebody who had to be behind closed doors arguing passionately on my behalf. But at the end of the day while performance currency gets your name on the list that's being discussed behind closed doors, when your name is called, if no one else in that room can speak on your behalf, they just go to the next name and it has nothing to do with your ability to do the job.
Build powerful alliances and maintain a diverse mix of relationships. We are in a very competitive economy. In fact, in the technology industry, there are tons of smart people, even smarter than you. When 10 people are drafted for an opportunity, and y'all have an amazing body and portfolio of work…WHO WILL SPEAK ON YOUR BEHALF?
- Law of Furthest Abstraction - The "Law of Furthest Abstraction" says that you have no knowledge of the underlying system where your code runs
- The Law of Inherent Scale - The Law of Inherent Scale says that scaling is an intrinsic attribute of the technology; so much so that it just happens automatically
- Law of Least Consumption - The Law of Least Consumption says that you only pay for what you use. Coincidentally, this also everyone's most favorite law. Money talks. But it doesn't buy happiness. But it does buy jetski's and I've never seen an unhappy person on a jetski
Obsessing with "clean code" and removing duplication is a phase many of us go through. When we don't feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured. A set of strict lint rules, a naming schema, a file structure, a lack of duplication.
Am I saying that you should write "dirty" code? No. I suggest to think deeply about what you mean when you say "clean" or "dirty". Do you get a feeling of revolt? Righteousness? Beauty? Elegance? How sure are you that you can name the concrete engineering outcomes corresponding to those qualities? How exactly do they affect the way the code is written and modified?
Coding is a journey. Think how far you came from your first line of code to where you are now. I reckon it was a joy to see for the first time how extracting a function or refactoring a class can make convoluted code simple. If you find pride in your craft, it is tempting to pursue cleanliness in code. Do it for a while.
But don't stop there. Don't be a clean code zealot. Clean code is not a goal. It's an attempt to make some sense out of the immense complexity of systems we're dealing with. It's a defense mechanism when you're not yet sure how a change would affect the codebase but you need guidance in a sea of unknowns.
Why domain knowledge and long-term visions are as important as technical skills
First of all, domain knowledge and long-term visions give meaning to your everyday work. Which one of the following excites you more: "write this code to finish this three-point story" or "write this code to remove one of the limitations of the system which brings us one step closer to handling large traffics and serving more customers"?
Secondly, domain knowledge and long-term visions serve as your compass for making decisions, big and small. How many people does the team need to hire this year? Which projects need to be worked on this quarter? Which approach should we use to solve this problem? Engineering is about making tradeoffs. There's no objective best solution. What you care about is the solution that works the best for your current context. Domain knowledge and long-term visions provide you the context to prioritize things and make decisions.
How to gain domain knowledge and form long-term visions
- Getting your hands dirty: experience, experience, experience
- Use the 5 Whys Technique
- Pick senior engineers' brains
- Building a solid technical foundation
Thanks for reading, hope you're having a good day