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.

7 Hard Truths for New Software Developers

TLDR;

  1. You don't actually know everything
  2. You will not get as much help as you need
  3. Tech is only half the battle; soft skills do matter
  4. You don't need to reinvent the wheel to make a difference
  5. You may not end up at Google or Facebook
  6. You won't understand everything you're doing
  7. Your evaluative metrics have shifted

11 Growth Principles to Become a Valued Software Engineer

TLDR;

  1. Master Your Tools
  2. Learn Every Day
  3. Communicate
  4. Improve Your Writing
  5. Unblock Yourself
  6. Own Your Projects
  7. You're Running a Business
  8. You're a Professional
  9. Done is Better Than Perfect
  10. Expect Change
  11. Learn When to Say No

Learning embedded programming as a software engineer

TLDR;

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?

7 Pro Writing Tips for Devs, Founders and Other Non-Writers

TLDR;

  1. Figure out your audience
  2. Choose an interesting topic
  3. Read for inspiration
  4. Decide the length of your post
  5. Develop a content structure
  6. Write shorter sentences for skim readers
  7. Practice makes perfect

What a difference a year makes in software development? Get in shape for 2020!

TLDR;

  1. Chase a career, not a job
  2. Personal projects
  3. Coding is the fun part
  4. People are unpredictable
  5. The illusion of easy money
  6. I am better then I think I am
  7. I'm not as good as I think I am
  8. Trust people
  9. Learning and development opportunities
  10. People don't leave organizations. They leave managers
  11. Teach others what you know
  12. My smile, still, stays on
  13. Don't hide your mistakes
  14. Process, Process, Process
  15. Stay committed
  16. Stay motivated
  17. Write
  18. Ability to influence and persuade

Software Is About Developing Knowledge More Than Writing Code

TLDR;

  • Don't silo people based on their skillset
  • Embrace cross-functional teams
  • Explain alternatives and choose the best solution together

The Hardest Part About Learning Hard Things

TLDR;

  • Learning is Frustration
  • How Do You Change Your Beliefs About Learning?
  1. Dive Straight In
  2. Avoid Comparison
  3. Embrace the Frustration

11 Essential Skills Software Developers should Learn in 2020

TLDR;

  1. Containers (Docker and Kubernetes)
  2. Cloud Platform (AWS, GCP, or Azure)
  3. Data Structure and Algorithm
  4. A Version Control Tool (Git)
  5. One Text Editors (VIM)
  6. IDEs (VSCode or IntelliJIDEA)
  7. Database and SQL
  8. UNIX (Linux)
  9. An OOP Programming language (C++, Java or Python)
  10. Networking basics
  11. One Scripting language

Who is Speaking On Your Behalf?

TLDR;

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?

If a service doesn't do these 3 things, it's probably not Serverless

TLDR;

  • 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

Goodbye, Clean Code

TLDR;

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.

The other side of technical skill: Domain Knowledge and Long-term Vision

TLDR;

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

  1. Getting your hands dirty: experience, experience, experience
  2. Use the 5 Whys Technique
  3. Pick senior engineers' brains
  4. Building a solid technical foundation

Thanks for reading, hope you're having a good day