Working for a startup earlier in my career was a boon, since I built most of my career capital during these formative years. Plenty of mistakes, plenty of reflection of how to create a resilient systems and along the way plenty of studying other successful engineers and companies to emulate and adopt best practices.
The following books were foundational for me in making me a good software engineer:
Think first, Type Later!
I spend significant amount of time upfront deconstructing requirements, how will I test it, what is the definition of done beyond - "Its working on my machine!". I would document rudimentary wiki on entity relationship diagrams, basic class diagram and a cursory module documentation outlining my design decision and the "why" behind my design decisions.
TDD, TDD, TDD - Any language I studied, Java, Python , Ruby - I was obsessed with JUnit or PyUnit and code coverage tools.
TDD forced me to clarify requirements before I start typing the program. It forces you to think through scenarios of acceptance criteria, clarifying the requirements up front. Since without a clear problem understanding, one can never achieve a good test coverage.
The practice of TDD paid off, since focussing on quality over the long tenure of my engineering contribution, I was able to build credibility of quality contribution.
Focus on quality vs. quantity. I would rather have 3 things I never come back to unless requirements changes vs. 6 things with poor quality.
The clean code book's suggestion of a single method no longer than 10 lines is easier to maintain, follow Single Responsibility Principle and not to mention apply TDD and achieving code coverage easily.
Martin Fowler : “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
This was my guide post for ensuring the code I write can be understood by a graduating CS final year student.
During my start up days, hiring fresh graduates from SDSU, this principle paid off in the long run. Handing over existing systems to a newbie was easier, since code was easier to read and understand.
My litmus test for my contribution followed Martin Fowler's principle or not was - I measured how many times the engineer taking over post hand-off tutorial is coming back to me for clarification.
Following YouTube content shaped my work ethic as an individual contributor early on.
Focus on High Leverage Activities
Leverage = Impact Produced / Time Invested
Optimize for Learning
Prioritize Regularly
Invest in Iteration Speed
Measure what you want to Improve
Validate your ideas early and often.
Improve project estimation skills.
Balance Quality with Pragmatism
Reduce Operational Complexity
Fail Fast
Relentlessly Automate
Invest in your team's Growth
It’s all about the fundamentals.
Be good at something.Work hard. Be prepared.
Have specific dreams. Never lose the child-like Wonder.
Brick walls are there for a reason.
When you don’t get what you want, you get experience.
It’s not what you say, but how you say it.
Get somebody to be reflective.
Get a feedback loop and listen to it.
Show gratitude.
Find the best in everybody.
Always have fun!
Don’t complain. Just work harder.
When Nobody’s Saying Anything to You Anymore, That Means They Gave Up.
Leadership Skills from Captain Kirk.
If you lead your life the right way, your dreams will come to you.
Edward Deming's principle - Cease dependence on outside agency for validation -Bake quality in.
If it hurts, do it often (It == deployment)
CI/CD is the way forward to iterating faster
Continuous feedback through massive automated pipelines.
Jez Humble's talk inspired me to study deeply Edward Deming and TPS
The talk had a profound impact on making me think about, can one reverse engineer the business logic of the code to write reading reading Unit Test Code?
Watching this talk, I internalized few foundational principles for how to write good testable code. What transpired as I adopted was the code was much simpler.
Rule of thumb for me later in life - if I am scratching my head seeing a code blob, how to test this - implies the code is not written in a simpler, logical way with testability in mind.