sglavoie.com – Tag: Career

Book summary: The Effective Engineer

Sébastien Lavoie — Sun, 16 Apr 2023 14:49:00 -0600

Introduction

This wonderful, mostly non-technical book is a compilation of the best practices and lessons learned by the author, Edmond Lau, during his impressive career as a software engineer. It is a must-read for anyone who wants to improve their skills and become more effective at what they do. The following are short excerpts from the condensed knowledge found in the book, sprinkled with some minor comments of my own along the way. These are extracted from the book’s takeaway sections and headings: I wholeheartedly recommend reading the work in its entirety for an immersive exposure to the fantastic storytelling capabilities of Edmond!

Book summary

Part 1: Adopt the Right Mindset

Focus on high-leverage activities

Leverage = Impact produced / Time invested

Leverage is the ROI for the effort put in.
Meta-skills are important to know where to focus one’s time and energy to translate more of one’s efforts into impact.
Leverage your time by always finding ways to perform activities quicker and making sure those activities will have a meaningful impact.

Optimize for learning

Make your learning rate a priority: it compounds like interest over time.
Study code for core abstractions written by the best engineers at your company.
Write more code.
Go through any technical, educational material available internally.
Master the programming languages that you use.
Send your code reviews to the harshest critics.
Enroll in classes on areas where you want to improve.
Participate in design discussions of projects you’re interested in.
Work on a diversity of projects.
Make sure you’re on a team with at least a few senior engineers whom you can learn from.
Jump fearlessly into code you don’t know.
Learn new programming languages and frameworks.
Invest in skills that are in high demand.
Read books.
Join a discussion group.
Attend talks, conferences, and meetups.
Build and maintain a strong network of relationships.
Follow bloggers who teach.
Write to teach.
Tinker on side projects.
Pursue what you love.

Prioritize regularly

Track to-dos in a single list.
Focus on what produces value directly.
Focus on the important and non-urgent.
Limit the amount of work in progress.
Use implementation intentions (if-then planning).
Prioritize routinely.
Write down and review to-dos.
Reduce context switches.

Part 2: Execute, Execute, Execute

Invest in iteration speed

Move fast to learn fast.
Invest in time-saving tools.
Shorten your debugging and validation loops.
Master your programming environment.
Get proficient with your favorite text editor or IDE.
Learn at least one productive, high-level programming language (scripting).
Get familiar with UNIX (or Windows) shell commands.
Prefer the keyboard over the mouse.
Automate your manual workflows.
Test out ideas on an interactive interpreter.
Make it fast and easy to run just the unit tests associated with your current changes.
Don’t ignore non-engineering bottlenecks.

Measure what you want to improve

Use metrics to drive progress.
Pick the right metric to incentivize the behavior you want.
Instrument everything to understand what is going on.
Internalize useful numbers (e.g., number of active users, requests per second, amount of data accessed and written daily, etc.).
Be skeptical about data integrity.
Log data liberally, in case it turns out to be useful later on.
Build tools to iterate on data accuracy sooner.
Write end-to-end integration tests to validate your entire analytics pipeline.
Examine collected data sooner.
Cross-validate data accuracy by computing the same metric in multiple ways.
When a number does look off, dig into it early.

Validate your ideas early and often

Find low-effort ways to validate your work.
- Approach a problem iteratively to reduce wasted effort.
Continuously validate product changes with A/B testing.
- Reduce the risk of large implementations by using small validations.
Beware the one-person team (you need feedback early to make sure you’re working on the right thing!).
Be open and receptive to feedback.
Commit code early and often.
Request code reviews from thorough critics.
Ask to bounce ideas off your teammates.
Design the interface or API of a new system first.
Send out a design document before devoting your energy to your code.
If possible, structure ongoing projects so that there is some shared context with your teammates.
Solicit buy-in for controversial features before investing too much time.
Build feedback loops for your decisions.

Improve your project estimation skills

Project estimation is one of the hardest skills that an effective engineer needs to learn. But it’s crucial to master.
To produce accurate estimates:
- Decompose the project into granular tasks.
- Estimate based on how long tasks will take, not on how long you or someone else wants them to take.
- Think of estimates as probability distributions, not best-case scenarios.
- Let the person doing the actual task make the estimate.
- Beware of anchoring bias (e.g., hearing about a low estimate from someone else may skew our own estimate later to be too low).
- Use multiple approaches to estimate the same task (e.g., estimate from past experiences, decompose a larger task into smaller ones and estimate each one).
- Beware the mythical man-month. Having more people on a project doesn’t necessarily mean it will be completed faster. Communication overhead, context switching, and other factors can slow down the team as much as $O(n^2)$ considering the number of people involved.
- Validate estimates against historical data.
- Use time-boxing to constrain tasks that can grow in scope.
- Allow others to challenge estimates.
Allow buffer room for the unknown in the schedule.
Define measurable milestones.
Do the riskiest tasks first.
Know the limits of overtime.

Part 3: Build Long-Term Value

Balance Quality with Pragmatism

Establish a culture of reviewing code.
- Catch bugs or design shortcomings early.
- Increase accountability for code changes.
- Provide an avenue for sharing best practices.
- Increase long-term agility.
Invest in good software abstractions to simplify difficult problems.
- Reduce the complexity of the original problem into easier-to-understand primitives.
- Reduce future application maintenance and make it easier to apply future improvements.
- DRY principle: solve the hard problems once and re-use the solutions multiple times.
Scale code quality with automated testing.
- Make large refactors with confidence.
- Offer executable documentation.
- Don’t test everything: focus on the most important parts of the code and make sure everything critical is covered.
Manage your technical debt.
- Pay it periodically. Incur it when necessary to meet deadlines.
- Repay the debts with the highest interest rates first (i.e., focus on what produces the most leverage).

Minimize Operational Burden

Embrace operational simplicity.
- Increased complexity introduces more potential single points of failure.
- New engineers face a steeper learning curve when learning and understanding the new systems.
- Effort towards improving abstractions, libraries, and tools gets diluted across the different systems.
- Do the simple thing first.
Build systems to fail fast.
- Pinpoint the source of errors.
- Make debugging easier by not masking your errors and by not deferring failures until later.
Relentlessly automate.
- Don’t underestimate the future frequency of the task.
- Internalize the time savings over a long time horizon.
- Automate mechanics over decision-making.
Make batch processes idempotent.
- At least, make processes “retryable” if they cannot be made idempotent.
Hone your ability to respond and recover quickly.
- Plan and practice failure modes.

Invest in Your Team’s Growth

Make hiring everyone’s responsibility.
- Identify which qualities you care about the most in your colleagues: keep the bar high.
- Make sure the recruiting process is effective.
- Adapt interview problems to different levels of difficulty based on the candidate’s experience.
Design a good onboarding process.
- Ramp up new engineers as quickly as possible (e.g., with codelabs).
  - Help the people around you be successful.
- Impart the team’s culture and values (e.g., have onboarding talks).
- Expose new engineers to the breadth of fundamentals needed to succeed (e.g., with mentorship).
- Socially integrate new engineers onto the team (e.g., give them starter tasks to feel they’re part of the team faster).
Share ownership of code (increase the bus factor).
- Avoid one-person teams.
- Review each other’s code and software designs.
- Make sure the team is exposed to different types of tasks and responsibilities regularly.
- Focus on readable and high-quality code.
- Share software decisions and architecture clearly.
- Make sure code and workflows are documented properly.
- Invest in teaching and mentoring.
  - The more effective the team becomes, the more freedom there is to work on new projects.
Build collective wisdom with post-mortems (e.g., at NASA, these become the user manual).
Build a great engineering culture.
- Optimize for iteration speed.
- Always automate.
- Use the right software abstractions.
- Nurture a respectful working environment.
- Allot experimentation time.
- Foster a culture of learning (CI/CD: continuous improvement, continuous delightfulness).
- Hire the best!

Conclusion

Edmond opened my eyes to the importance of being an effective engineer, showing what that entails and how to concretely achieve it. His extraordinary technical journey and knowledge of the field are evident throughout the book, and I found myself nodding in agreement with many of his points. He made me think about how I could apply his advice to my own work. Notably, the key concept of leverage resonated deeply with me and ended up being the cornerstone of the final project I built for my bachelor’s degree: ProductiviDo - An efficient task planner focusing on high-leverage activities.

Resources and references

Edmond Lau - The author’s personal website.
ProductiviDo - A simple and efficient todo-app built with React-Native.
The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact - goodreads.com.
The Effective Engineer - by Edmond Lau.

What it took to propel a career in tech in five years

Sébastien Lavoie — Sat, 18 Jun 2022 14:22:00 -0500

After having kept a concise (and incomplete) log of my technical learnings for five years at this point, I can see I’ve come a long way, yet this is only the beginning. From now on, it is time to focus on taking concrete action, build on the foundation that has been laid out over time and start appreciating life from a broader perspective, too, as there are of course many aspects that have contributed to put me at this exact spot on this journey. Theory leads to a deeper understanding in any field, but in the end, the results being produced are what matter most and spending quality time getting good at one’s craft is key to making real progress. I think the most important steps to take in this context are getting into the habit of learning constantly and working towards generating a profound desire to excel, just for its own sake.

To glory and beyond!

The output below was formatted automatically with a tool that converts the content of a Google Sheet into Markdown. If you’re curious, you might enjoy reading this article!

2022

April

Articles
- Google Cloud Platform
  - Access control lists (ACLs)
  - Set up OS Login
- React
  - JSX In Depth
- Technology
  - Flutter is better than React Native
- Web development
  - How I built a modern website in 2021
University of London
- 3D Graphics and Animation
  - Computer Graphics: From Pixels to Programmable Graphics Hardware (book)
    - Lighting models and shading
    - Transforms in 3D
  - How to set up a Unity project in GitHub
  - LEARN UNITY - The Most BASIC TUTORIAL I’ll Ever Make
  - Unity
    - Orientation
    - Coordinates
    - 3D models
    - Components
    - Lights, Prefab
    - Essential Unity Concepts
    - Basic movement, building a scene
    - Types of light
    - Script communication
    - Physics and collisions
    - Movements and forces
- Mobile Development
  - Adaptivity and Layout
  - App Development
  - Core Components and APIs
  - Dark patterns
  - React Native Express
    - JavaScript
    - React
    - Core Components
  - React Native flex
  - React Native – Programming UI elements
  - React Navigation
    - Read documentation
  - Skeuomorphism, minimalism and neumorphism
  - Universal Access in Human-Computer Interaction (book)
    - User Interfaces in Dark Mode During Daytime – Improved Productivity or Just Cool-Looking?
    - Impact of Sentence Length on the Readability of Web for Screen Reader Users
  - Wireframing
YouTube
- Bash
  - bash quoting is really not that difficult!
- Git
  - Git Annex Is The Coolest Program You’ve Never Heard Of
- Graphic Design
- NFTs
  - You’re Wrong About NFTs
- React Native
  - React Native Tutorial for Beginners - Build a React Native App
- Software design
  - How To Avoid Big Upfront Design
- Software engineering
  - What Software Architecture Should Look Like
- TDD
  - How To Perfect Software Design With Test Driven Development
- Unity
  - Learn Unity - Beginner’s Game Development Tutorial

March

Articles
- Data science
  - The Complete Guide to Time Series Analysis and Forecasting
- Django
  - How to Create a Custom Django User Model
  - Writing your first Django app, part 5
    - Testing in Django
- Docker
  - Networking with standalone containers
- JavaScript
  - Immer.js 101 — Making Redux state updates in React predictable
- Security
- Streamlit
  - Visual time series forecasting with Streamlit Prophet
Documentation
- Django
  - Signals
University of London
- Databases and Advanced Data Techniques
  - Review course concepts (see past entries)
YouTube
- Django
  - Build an Asynchronous Chatroom with Django and Channels
  - Django & React Authentication
    - Password reset
    - Sign Up & Account Activation
  - Docker - Django, Celery & Redis Docker Compose setup
- React Native
  - Build an Instagram Clone with React Native, Firebase Firestore, Redux, Expo

February

Articles
- Python
- Terraform
  - The easiest way to run a container on GCE with Terraform
Books
- Terraform
  - Terraform in Action
    - ch. 1
Courses
- Google Cloud Platform
  - Google Cloud Platform Fundamentals - Core Infrastructure
- Python
  - Build Web Apps in Python with Streamlit
- Terraform
  - Implementing Terraform with Google Cloud Platform
  - Terraform - Getting Started
Documentation
- Google Cloud Platform
- Terraform
  - Get Started - Google Cloud
University of London
- Advanced Web Development
  - Learn React & Django - Chatroom Concept - React Django+Channels Chatroom Heroku Deploy
YouTube
- Blender
  - Blender 3.0 Beginner Donut Tutorial
    - whole series
- Django
  - Building a Social Media App With Python 3 and Django
    - Replying to Comments
    - User Notifications
    - Adding Images to Posts
    - Sending DMs
    - Finishing DMs
    - Sharing Other Posts
    - Tags
    - Finishing tags
  - Django & React Authentication
    - Navbar and check authenticated status
  - Django & React Tutorial
  - Django + React Notes App
  - Django Channels & WebSockets Oversimplified
  - Django REST Framework Tutorial Class Based Views Pt. 1
  - Django REST Framework Tutorial Class Based Views Pt. 2
- Python
  - Python lists remember what you did to them

January

Articles
- Docker
  - How to SSH into a Running Docker Container and Run Commands
  - How to squash Docker image
- Mastering the craft
  - What Makes a Senior Developer… Senior?
- Python
  - Logging in Python
- SSH
  - How to access a Linux Server using an iOS device
Books
- Docker
  - Docker Deep Dive
    - ch. 1-6 (Docker engine, images)
    - ch. 7 (Containers)
    - ch. 8 (Containerizing an app)
    - ch. 9 (Deploying apps with Docker Compose)
Documentation
- Cloud
- Django REST framework
  - Schemas
- Python
- Slack
  - Web API methods
University of London
- Advanced Web Development
  - Asynchronous Web Services (Celery, Django, Pillow)
  - Attacks on websites (XSS, CSRF, SQL injection, clickjacking)
  - Consuming WebSockets
  - Deployment automation
  - Django authentication and administration
  - Django channels
  - Introduction to production deployment
  - Introduction to web sockets
  - Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP
  - OpenAPI
  - Profiling and performance
  - Scaling and load balancing
  - Tutorial Pillow (Python)
  - Web APIs
- Databases and Advanced Data Techniques
  - Distributed Relational Databases
  - Document databases and MongoDB
  - Introduction to Linked Data and the Semantic Web
  - Introduction to semantic databases
  - Linked Data in a Graph Database
  - Multimedia databases and Information Retrieval
  - Using XML
  - XML Schemata
YouTube
- Django
  - Building a Social Media App With Python 3 and Django
    - Landing Page and User Authentication
    - Posts and a Social Feed
    - Get a Post and the Comment Model
    - Edit Posts, Delete Posts, Add Comments
    - Profiles
    - Followers
    - Likes and dislikes
    - User search
    - Final improvements Part 1
    - Final improvements Part 2
- Linux
  - Linux File System Structure Explained

Book summary: Letters to a New Developer

Sébastien Lavoie — Mon, 08 Nov 2021 10:12:00 -0600

Introduction

I’ve taken quite a few notes while devouring that book, which is a quick and easy read. It’s not the typical non-fiction, technically-oriented manual: this book makes you feel like having an older family member taking the time to sit right next to you to openly share all sorts of golden nuggets from a lifetime of rich and varied experiences so you can get prepared to face the challenges that lie ahead in your own career and avoid some of the more common mistakes during the journey. It is the kind of publication you can read literally five minutes at a time thanks to the convenient format it adopts.

Some of the following notes are verbatim and reading the whole title will be worth it! Nevertheless, you will find below some passages that deeply resonated with me, reflecting the gist of this prose from my perspective. Beware! There are numerous gems to be gleaned from this excellent author.

Book summary

First month at a job

See problems as opportunities to contribute.
During the onboarding, figure out:
- All the HR stuff: benefits, agreements, bonuses, interacting with different departments, meetings, requesting vacation, raises/reviews cycles.
- And the technical stuff too: who to ask questions to, how to ask them (batch them, chat, meeting, etc.), how long to work on a problem before asking for help, how to communicate progress, how to set up a local development environment, CI/CD and branches process, when do you know you’re done working on a task, how are tasks managed (manager, issue tracker, etc.).
Questions that arise and have no answers → See where to document them (e.g. wiki).
First impressions:
- Be there early.
- Say what you’ll do, then do it.
- Research before asking questions (and record answers).
- Volunteer to take extra work (don’t become a punching bag, though).
- Own your mistakes but don’t make the same ones twice.
- Be polite and professional, always.
- Make sure with manager we’re on the same page, working on the right stuff, at the right cadence with appropriate updates.
- Write docs to make the next hire easier.
- Have the reputation to be a hard, smart worker: it will follow you.
Be ready for the trepidations: celebrate successes ("today I [fixed, learnt…]").
To excel:
- Communicate what you’re working on.
- Ask questions.
- Don’t make the same mistake twice: write down what went wrong and plan to avoid repeating them.
- Show up consistently.
Know the team: their names, their roles, their behaviours (who posts what, who is in which meetings, who seems funny and approachable on Slack, etc.).
Read code and take notes: dig into a section of the system, follow data flow, make diagrams of how things are connected.

Questions

Ask prepared questions:
- Research before asking.
- Find where to search (Slack, issue trackers, YT, internal docs or wiki, etc.).
- But also be mindful of how long you should spend time searching (Is there a tight deadline? Are you wasting your time?).
Ask good questions:
- Specify the problem in detail, narrow the scope as much as possible.
- Show you’ve done research. Links, videos, posts, logs (without sensitive info), etc.
- Follow up after a day or so to share additional research.
- Express gratitude.
- If you have the answer, add it.
Don’t be afraid to ask questions:
- If it’s a learning experience, spend more time figuring out the answer.
- The more time you have before the task is due, the more time you should spend looking for an answer.
- How busy is the rest of the team? If they can’t help, you’ll have to do it yourself.
- If there’s a bug that’s really specific to the internal project, asking for help from coworkers is probably best (be careful not to disclose business knowledge!).
- Have you tried working on other aspects of the task? It may unblock you.
- Put in the effort before asking: research, list hypotheses, etc.
Ask why:
- It may help prevent mistakes down the line (e.g. wrong choice of tech) and get more perspective, understand better.
- Document findings in wiki or similar (could be in a question/answer format).
If you don’t know something, don’t guess or make an incorrect decision: admit it and say you’ll find out the answer (may have to ask others in the process too).

Writing

Read your texts out aloud: spot typos, awkward sentences, etc.
Document the intent behind what you’re doing (code, reason for change, who asked what…).
Emails:
- As short as possible. Otherwise, add executive summary at the top.
- Is it sensitive? Maybe have face-to-face instead.
- Add links to supporting documents rather than attaching them. Email chains are hard to follow: may put them in a document instead.
- Don’t use relative time references.
- Keep them focused: go into one topic. New topic = new email with different subject line.
Real-time messaging: Default to public channels to benefit the organization.
Write a technical ebook: working on a complex project over time and being able to see the high-level and details, all presented in a coherent way for the readers.
Write and update technical documentation: you save time in the long run, it’s useful for you and the rest of the organization.
Blog: this is the process of clarifying your own thoughts. You’ll be a better writer and thinker for it.
Motivation about writing:
- It crystallizes thoughts, make them clearer;
- Builds credibility;
- Helps others;
- Illustrates an ability to convey technical information and context.

Tools to learn

Leverage for increased productivity:
- Test suite: living documentation. Can evolve code base without fear.
- Libraries and frameworks: saves time.
- IaaS (infrastructure as a service, e.g. AWS EC2): can use APIs to manage.
- Paas (platform as a service, e.g. Heroku): Allows to focus on business logic.
- Saas (software as a service, e.g. Google Apps): integrate with existing software.
Command-line:
- Typing is quicker than using GUIs for many tasks.
- Can automate recurring tasks easily.
- Can easily share task scripts with others.
- jq, awk, sed: put them to good use.
Version control: if in doubt, use it, except for large files and other scenarios that don’t make sense.
Text editor: learn one well.
IDEs: Use them when it makes sense (programming in Java with a text editor? Probably a bad idea).
Standard library: get a good overview of what’s available, leads to transferable skills, more idiomatic code, better tested, etc.
Automated testing:
- Prevents bug regression.
- Serves as live documentation.
Network engineering: Learn about it, it will pay off. Know:
- Basics of routing;
- Basics of DNS;
- Rundown of the OSI model;
- TCP/IP, HTTP, what a proxy is;
- Answer questions like How do CDNs work, what’s the difference between HTTP and WebSockets, how does SSL work, what can nginx be used for…
SQL: this is fundamental knowledge as it’s almost everywhere.
Debuggers: learn how to debug in your IDE, on the command-line and in a web browser (your IDE won’t always be available).
Benchmarking: do not optimize prematurely and use benchmarking tools when performance matters to see if the code is fast enough.
Search engines: learn to be an expert Googler.

Practices

Solve problems, don’t just write code:
- Use library/framework.
- Use third-party SaaS tool.
- Make sure tasks need to be done. (Why are you doing it? Does it provide value?)
- If a task isn’t recurring often enough, manual work may be the best way to go (time to automate vs. actual savings).
Think ahead, envision all paths (not just the happy one) before taking a decision.
Read code: scan it; dive down; use the scientific method to make changes and debug.
Get good at estimating your work:
- Opportunity cost (can’t do everything: prioritize and do the tasks that bring the most value).
- Scheduling: software is not built in a vacuum, hard and soft deadlines will occur.
- Discussing requirements first can save a lot of troubles and money: building the wrong thing quickly is of no use. Use lightweight prototyping tools instead of building the whole software.
- Recommended reading: Software Estimation: Demystifying the Black Art, by Steve McConnell.

Here’s one way to keep track of your estimates in a spreadsheet:

Task	Low estimate	High estimate	Notes, questions, research	Final estimate	Estimate in days
Requirements definition, research, development, testing, deployment, estimates on bug fixes…	Everything going smoothly.	Facing obstacles, having to rebuild part of the system, etc.	Answer questions and verify assumptions to complete the estimate.	(low + high) * 1.2 (add 20%, “fudge factor”)	Total hours estimated divided by number of ideal hours per day

Tracking the actual accuracy of tasks can be insightful too.
Always tell people who are depending on the completion of a task if it’s going to take longer than expected. Share alternative solutions if you have any.
Even for side projects or when working on open source projects, it may be useful to practice estimating (and users like seeing a roadmap).
Debug systems:
- Make the problem as simple as possible.
- Begin with an hypothesis and either prove it or refine it.
- Determine the desired end state: fix the root problem but if it’s too costly, find a workaround if possible.
- Pay attention if anything seems amiss.
- Keep notes about what you’ve tried.
- If there’s a new bug, inspect recent changes in the log.
- Write an automated test before fixing the bug so it doesn’t reappear and you’ll be sure when the bug was fixed.
- Follow the flow of data (e.g. in a three-tier application, start with the browser or with the database).
- Minimize impact for users if the bug is in the production environment. Ideally, test on the staging environment.
- Test the right thing. Make sure that what’s being tested mirrors as closely as possible where the bug appears.
Assume positive intent: be solution-focused.
- ROI on trust: about 4% of the population are sociopaths; meaning 96% of the population has some working conscience and could be trusted by default to reap great benefits. This may speed decision making, for instance.
Express gratitude: it will make you feel better and showing appreciation to others will make working with colleagues a breeze. Thanking people and writing a gratitude journal will be helpful.
Cultivate the skill of undivided attention:
- To produce your best output, you need to commit to deep work.
- To thrive in today’s economy, you need to be able to quickly master hard things and be able to produce at an elite level in terms of both quality and speed.
- To learn hard things quickly, you must focus intensely without distraction.
- Add routines and rituals to your working life to limit the amount of willpower required to get started.
- Book recommendation: Deep Work: Rules for Focused Success in a Distracted World, by Cal Newport.
Build empathy: Remember your own frustrations. Your users are people who can struggle on tasks you’d find simple yourself. They’re trying to make something work, just like you.
Don’t complain about the code:
- It’s not helpful.
- It displays a lack of empathy.
Avoid jargon: If you can’t explain it to a non-technical user, you don’t understand it well enough (good framework: try the Feynman Technique). You gain clarity for yourself, the ability to teach others and you can influence your organization. (Personal additional: get good at critical thinking and use frameworks for better thinking).
Time is money: buying services from others gives you time.
- Buying a book or video instead of reading free documentation.
- Buying and using exceptional tools (e.g. JetBrains IDEs).
- Paying for support.
- Buy commercial software.
- Pay for consulting or training.
Say no:
- If there are pending tasks, ensure they are worked in the right order of priority.
- Life is short: if you end up working 90 hours per week, make sure you’re happy doing it and are not sacrificing other important aspects.
Build on your own: pick a project you can envision yourself sticking to for more than six month and learn.
Consistency is key: learn by showing up every day. Becoming great at something takes time.

Understanding the business

Software is about people, not code:
- Software is created for people.
- Users need to be heard to buy in.
- Most people don’t care about the code. Their goal is to get things done. Beautiful code that doesn’t solve the right problem is useless.
Outcomes over output: the end-goal for the business is more revenue, more profit, more users, more product availability, happier users, etc. Your contributions should be holistic in nature and work towards achieving these goals.
Understanding the big picture of why money is spent on certain projects or services pays off as you can better contribute to the bottom line of the company by knowing why things are done the way they are.
Business model: know how money is being made. Get a good understanding of the domain in which the business operates.
Knowing how software is used at the company helps you to understand the business.
The size of a company impacts how it solves problems: a bigger company will usually move more slowly towards its goals when change is required, attacking possibly bigger problems with powerful tools and teams. A smaller company may pivot more quickly and shift focus, but it may not work on problems of comparative scales.
Starting a company:
- As a new developer, starting one wouldn’t be wise. Learning to become a software developer and learning how to run a business all at once can lead to a huge amount of stress.
- It will take longer than you think.
- Know your financial runway (“burn rate” vs. what you have in the bank). Extend it by lowering the burn rate.
- Consider your emotional runway: how are things going for you outside of work? Are there any trying events like moving or having a new baby?
- Talk to your customers: learn from them. Get feedback.
- Provide value to customers: you won’t have time to make everything go as smoothly as you’d like, but the customer must still be served.
- Know your market.
- Be ready to move away from code and focus more on a position of management as the company grows.
Learn from your customers:
- Digging into a ticketing system will be informative to understand how a product is being used and may reveal flaws or bugs.
- Focus on the problems mentioned, not on the solutions proposed.
- Ask them about their pressing problems, not only those that have been reported so far. This may inform about issues with related systems.

Learning

Never stop learning:
- Be clear about why you want to be learning.
- Once you have the why, determine the what that will take you there.
- Once you have both of the above, find the how.
- Execute.
Build expert intuition:
- It’s the difference between a junior and a senior developer.
- A regular world + many opportunities to learn + frequent feedback + expert intuition.
- Regular world: gives a chance to find out whether you’d prefer to specialize in a specific branch of the software development tree or remain a generalist.
- Many opportunities to learn: write code, work on technical projects and observe those who are more senior than you.
- Frequent feedback: code reviews and one on ones with the manager. Reflect on your performance with a daily journal.
Know what to learn (i.e. general skills vs. specific technology and techniques):
- Domain knowledge: understand the business you are in, who the major players are, etc. If you stick in a given domain long enough, you become more valuable as this kind of knowledge tends to last a long time. Talk to experts and read books.
- Theoretical expertise: data structures and algorithms, HTTP and best practices fall within this category. It serves for years as a solid foundation for everything else. Books are a fine source to delve deeper.
- Practical knowledge:
  - React, Kubernetes, Rails are some examples of specific technologies that belong in this category.
  - Have a good understanding of the underlying technology whenever possible (e.g. learn the language in depth, not just the framework).
  - This type of knowledge tends to age quickly and can be learnt through videos, conference talks and tutorials.
- Leadership knowledge: This will pay dividends through your career. Books and experience in the real-world are useful here.
Avoid being an expert beginner (an authority with nontransferable skills):
- Never believe you have all the answers.
- Don’t bend tools to do something they weren’t meant to do.
- Don’t ignore best practices (but don’t blindly apply them everywhere either!).
- Keep in touch with the larger software community: you may temporarily be at the top somewhere technically speaking, but that won’t remain true in a bigger context.
- Pair with people that are more experienced than you: ask them questions, read the pull requests they submit.
Pattern match to be a just-in-time learner: explore by pattern and analogy (e.g. compare terminology that’s similar to tools you’ve used before) and learn just enough to get the task done. Learn the nuances as you go.
Learning boring stuff:
- Focus on the big picture. Why are you learning this?
- Notice the fun parts.
- Take breaks when needed. If no strict deadline is in sight, you might cross off a different task on your to-do list for now.
- Automate what you can but consider clearly the time savings when doing so.
- Learn relevant things: this applies once you have a base to lean on, but accumulating random concepts that aren’t often applicable after that isn’t useful (unused knowledge rots and gets forgotten).
Your team will teach you:
- They can teach you more than you can learn on your own: tools; languages; frameworks; business domain knowledge; approaches to problem-solving; understanding of the problem; stakeholder empathy.
- Observe how senior people work (face-to-face, read their code and pull requests).
Use an RSS reader: for blogs, online community discussions, tags in Stack Overflow, news sites.
Listen to podcasts: good to gather ideas about high-level concepts while doing other things (dishes, exercise, watering plants, cooking, etc.).
- Listen to those that are domain specific to help you at work.
- Technology specific: expose yourself to tools, techniques and libraries.
- General software development: those are broadly applicable to software engineering and will work across different jobs you have within the industry.
Subscribe to email newsletters: great to get curated content on a given topic. These could include software development practices, security, AWS and career skills.
- Find them with searches like <subject area> weekly/email newsletter.
- Read the archives first to get a sense of whether you’ll enjoy the content.
- Like with podcasts, focus on what’s interesting and skim the rest.
- When sources lead to more articles of interest, those can be captured in your RSS reader.
- Good to explore new technologies and frameworks.
- To start your own, TinyLetter is a great option.
Read great books about software development: don’t look for cutting-edge information but rather for a source of timeless practices.
- Good examples include The Mythical Man-Month, The Pragmatic Programmer, Refactoring.
- Ask great engineers you respect for recommendations.
Listen actively:
- Do not multitask.
- Take notes of… salient points; ah-ha moments; terms to review in the future (those concepts you may not understand). Note the date of the conversation as well.
- If it is a video chat, see whether it can be recorded. Turn on video if possible to get contextual clues.
Learn two programming languages:
- Lets you see the strengths and weaknesses of your first language.
- May support concepts that weren’t there before (e.g. classes in Java vs. their absence in Perl).
- Makes it easier to learn a third language.
- Illustrates different approaches to common problems.
- Teaches you how languages fit certain problems better than others.
- Makes you less passionate about your first language. Programming languages are only tools.
- Makes it clear what you understand about language #1.
- Tutorials are great to get started and side projects even better to cement the learning.
- Generally, learn at least two of “everything” (e.g. databases, frameworks, development methodologies, etc.).

Mistakes

Get used to failure: learning something new is difficult. Document internal knowledge as best as you can so the same mistakes do not repeat themselves. Look around (online, colleagues…) to make sure the problem you are trying to solve hasn’t been worked on already and take any new information into account.
Making mistakes is okay:
1. Find out what the oversight was so you don’t repeat the same mistake.
2. Acknowledge you made an error.
3. Clean up the mess, with or without help.
4. Avoid making the same mistake again. You might keep notes around, write a blog post, etc. Document it or create a script to solve the issue from now on if applicable and share your new knowledge with the rest of the team.
Mistakes are forgiven, hiding them is not:
- Make sure you did a mistake to start with.
- The people who need to know about your errors should be told. Transparency and honesty are important.
- Think of a plan to fix the mistake (both short-term and long-term).
Don’t make the same mistake twice:
- Make sure you understand what the mistake was.
- Dive deeper when it makes sense. For instance, it is worth mastering a version control system as this is a tool that’s going to be used all the time and is critical to understand when working with other software engineers.
Don’t be afraid to “fail”: the only true failure is to quit working towards success.
- Failures don’t stop happening when you become a “better” developer.
- The more you fail, the more you learn.
You don’t know what you don’t know. Doing pattern matching and recognizing concepts at a high level will help when there’s a need to dig deeper.
When you see someone else making a mistake:
- Make sure you have all the necessary context (you usually don’t have it) before jumping in to shine a light on how you think things could be done or fixed.
- Make sure you fully understand the issue at hand.
- Think about the ramifications of a poor decision: the higher the stakes are, the more likely it is that you should/could intervene.
- Contemplate your role: depending on the relationship you have with that person, tolerance levels will change (personal note: ask questions early as needed, but make sure you show progress as stagnation won’t lead to joyful relationships with your colleagues and may get you fired).
It’s OK to fail and it’s OK to feel bummed about it. See how core/important the task is for the company, whether somebody else would be better positioned to do it, how long it would take you to become good at it, whether you enjoy it, whether there’s another way to solve the problem, if there’s someone else at the company who could teach you. Don’t beat yourself up with despair: be strategic about the way you spend you efforts.
Admit your weaknesses… and own them.
- Is it something innate, like bluntness, or is it something you can learn, like Python?
- If a weakness is related to a core competency needed for your job, be proactive in overcoming the obstacle or find another job that’s better suited to your skills.

Your career

Favor learning over earning: take the job with the highest learning potential.
- Beware of stunting your growth by working alone.
- You will become more valuable to your future employers and have a better idea of what you like.
You will never be in a better position to leave a bad job than before you start: interviewing is a two-way street.
- Do your research before accepting a job offer.
- Investigate through your network, e.g. LinkedIn, if you have a connection that worked at that company and ask about the good and bad of this organization.
- Ask good questions about the company during the interview.
- As an exception, you might want to consider getting your feet wet in the industry with your first job by being less picky, especially if the job market is bad. Experience will prove useful.
Pick a flaw: no company is perfect.
- You don’t want an indifferent team just punching the clock and waiting for the week to be done.
- Avoid nonsense: ask how a typical day goes, who makes decisions about priorities, in what kinds of projects does the company shine and what the best and worst parts of a job are.
Preparing for a recruiting event. Have: a resume; a good intro to yourself; a good conversation you can have; be well presented.
- Resume: make sure you have the address, phone, email, GPA and graduation date (for students) at the top. It should show you’re motivated, skilled, passionate, adaptable, collaborative and articulate. When you have less experience, projects should be the centerpiece of your resume. Project descriptions should be brief and focus on the what, why and the outcome, avoiding mentions of tech stack unless it adds to the narrative. These can be side hustles, open source, personal interest or hackathons. Have more than one resume for different audiences.
Practice programming: you learn by doing.
Start at a consulting company if you’re looking to gain experience across technologies, domains and businesses. Work for a small one if you want to have an impact. This will provide contacts and set you up for future work. Seek out mentorship, request conference attendance and pursue assistance as formal education programs tend to be lacking in those environments.
Potential vs. delivery: Ask smart questions, show you’ve learned stuff. Say what you’re going to do, then do it.
- The more experienced you become, the more you are assessed on your ability to deliver.
- Expect to demonstrate your experience during interviews.
- Periodically, or when you complete a project, take a few minutes to write some lessons you’ve learned.
- Take risks early as pivoting later on in your career becomes more difficult.
- Book recommendation for more senior developers when switching domains, tech stacks or employers: What Color Is Your Parachute, by Richard N. Bolles, with Katherine Brooks.
Maintain work-life balance: preserve a firm boundary. Work is a marathon, not a sprint.
- Get clear on how the employer expects you to handle unplanned work with conflicting priorities.
Listen to the voices when they help and ignore them when they don’t:
- Be willing to do things you didn’t think you wanted to do.
- Connect with non-tech people outside of work to take a break and experience life from their point of view too.
Manage your career: know your goals; communicate your goals; progress towards them.
- Knowledge: pick an interest and follow it. Plan for a decade or more, with some milestones in between.
- Communication: communicate your desires and ambitions. Good companies want to see their employees grow.
- Progress: study for a certification, read a book, go to a meetup. Be active.
Know your runway: this is the time you have at your current spending until you have no money. Calculate it once a month and know how long it would take to get a new job (guess).
- Get a job before you need to to avoid accepting an ill-fitting job due to desperation.
- Cutting expenses is hard but it’s where you usually have the most control.
- Spending savings for a career transition is an investment in yourself.
- Activities that draw down your savings should lead to new opportunities and valuable personal knowledge.
Managing one on ones: for remote ones, it’s best to have a great Internet connection, a quiet space and video turned on (personal note: you do lose visual clues without video, but you can connect deeply without anyone being too self-aware with voice-only communication).
- Regular ones (weekly or bi-weekly) are preferred so you don’t dread feedback only when you ask for a raise or do something wrong. Knowing your manager beyond these scenarios will help.
- Reasons to schedule them: understand where we are headed so I know what to learn; know how I can best help the manager and the company; understand your priorities better.
- The direction of the one on one should be determined by the employee.
- Shoot for regular ones that do not get re-scheduled. Otherwise, propose having them less frequently if needed.
- If one-on-one meetings aren’t desirable, go for an asynchronous weekly status report and get feedback from your manager this way: it is critical for your career growth early on in your career.
- Come with a prepared agenda to make the most of them. A shared document in reverse chronological order works well. Example questions to add:
  - How should I have handled situation X?
  - I would like to learn more about Y; what are the opportunities?
  - I’m struggling with <problem>, do you have any suggestions?
  - What are the challenges you see facing our team during project Z?
- You should be able to trust and rely on your manager/boss. If not, improve the relationship or go elsewhere: being constantly under threat and not knowing what to expect is mentally draining.
Write a brag document: show everything you’re proud of so they know you’re a great team member. It should be thorough yet easy to read. Along with the agendas from your one-on-one meetings, it will serve to highlight your accomplishments for your next performance review.
Be adaptable and authentic.
Working remotely: you need a fast Internet connection; iron discipline; be okay with solitude and have the ability to work through communication obstacles.
- If you are comfortable asking a dumb question, remote work can work well for you.
- You will need to get used to asking questions and interrupting others as you more often than not won’t have enough context to infer whether it’s a good time to ask or not. It’s better than the alternative of wasting your time.
How to go through a layoff: this isn’t personal and you will get through it.
- Ask questions:
  - Know the deadline to sign the necessary documents;
  - Find out if there’s a severance and how much is it;
  - What about funds like 401k, FSA or HSA;
  - How can I say goodbye to teammates (emails and LinkedIn are good options);
  - What about company’s property, e.g. laptop, books and equipments;
  - Who can I contact if have I more questions;
  - Make sure they have your personal email;
  - Take notes of what happened;
  - Get involved with a lawyer before signing anything (e.g. non-compete agreements).
Use LinkedIn:
- Send a note when you connect and keep in touch with past colleagues.
- Ask recruiters about the job market, salary ranges for people with your experience and good skills to learn.
- Review your connections’ companies, review posted jobs and ask for introductions from your connections (let them know why the company is awesome, why you’re awesome and why you want to work there).
Contracting: try it during the first decade of your career.
- It’s easier than applying for a full-time job given you’re easier to let go.
- It will keep your skills sharp if you want to find clients.
- If/when you’re an employee again, job hunting won’t feel as scary.
- You will strengthen your network by being able to refer former colleagues.
- Contracting can be more lucrative on a per-hour basis.
- Contracting via an agency is easier (you avoid sales and accounting) but it pays less.
- Direct contracting is harder but you’ll learn beyond software development (sales, customer support, marketing, invoicing and chasing payments). It leads to more control over the clients you work with and more income. You may spend as much as 50% of your time on non-billable work such as seeking new opportunities: your rate needs to reflect this.
Engineering management: if you move to a management position, be prepared to be a novice again as the skill set involved is not the same.
- You should understand the code but keep out of the critical path.
- You shouldn’t make technical decisions.
- You are here to enable teams to do great work.
- The fun, technical stuff should only be done during hackathons.
- Be clear about what you want and maintain the right set of skills so you can keep doing what you enjoy the most.
Someday, you won’t want to code for a living: becoming a manager gives you leverage to have more impact in the world.
- Impact can be achieved through writing, project management, product management, speaking, starting a business, mentoring, leading a team, managing, teaching, architecting and consulting. Notice that coding is not the primary output.

Community

Building a community/network puts you in a situation where you can help people help others.
Meetups: find one on meetup.com.
- It will expose you to new ideas you can bring to your job.
- You can have professional conversations with low stakes.
- It gives you a way to practice talking to new people and make friends.
- It provides a network outside of your coworkers should you need to find a new job.
Conversational hooks: give some details about where you work and what projects you have been working on to give the chance to the other person to steer the conversation in the direction they want. Flip the question to ask people to talk about themselves (most people like to do that).
- Don’t make transactional conversations: find something interesting to talk about.
Online tech communities:
- Sign up for an email list related to the technologies you are interested in. Sign up for notifications on projects. You can follow project contributors on Twitter or other social media places.
- For something more general, have a look on Slack, forums, IRC channels, Facebook groups and so on. Slashdot, Hacker News, Reddit, Stack Overflow are other good options.
You get what you give:
- Offering to help makes you more empathetic and aware of other people’s needs.
- It feels good to help.
- You become less arrogant.
- You help build the positivity of the community.
- People will be quicker to recommend you for a job.
- It improves your sense of self-worth and confidence.
Build your work community:
- Use LinkedIn.
- Never leave a job on bad terms. Give the requisite notice, document your work and prepare for a hand off.
- Keep in touch with past coworkers, even if it’s just to leave a note on their work anniversary.
Three daily mantras:
- Surround yourself with people smarter than you.
- Build community and give without expecting anything in return.
- Listen to your gut, without exception.
Build a personal board of advisors.
- Some issues you can discuss with them that aren’t topics for current coworkers:
  - Someone under your supervision is not succeeding;
  - You have an issue with your manager that you’re not sure how to solve;
  - You are evaluating job offers.
- Make sure to keep these relationships fresh and offer to help too.
- This circle shifts over time: a new developer doesn’t have the same questions that a team lead would have.

Conclusion

That’s it: we went through a short overview of a book I’ve enjoyed and recommend heartily. You can find more on the author’s website. You might also enjoy a follow-up book summary about The Effective Engineer. May you live this knowledge!