Hiya everyone!

If you like what you read, please hit that like button, share it, or leave a comment so that the Substack knows to let more people read it. Please suggest a topic for a future essay here!

Share

There is no rule on how to write. Sometimes it comes easily and perfectly; sometimes, it's like drilling rock and then blasting it out with charges.

Ernest Hemingway

I wrote about how taking daily notes helped me through tough times, helped me grow, and showed me the value of writing. I do not take daily notes anymore; I take weekly notes instead. I found it the easiest way to start writing and avoid the "paralysis" phase. I love this quote by Stephen King: "The scariest moment is always just before you start. After that, things can only get better."

Writing is integral to personal and professional growth, especially for software engineers. It might sound counterintuitive, but it is one of the most effective ways to have more impact. Whether crafting documentation, communicating ideas, or jotting down creative thoughts, the art of writing enhances clarity, articulation, and, most importantly, understanding.

Writing, at its core, is an exploration—a journey into the depths of one's thoughts and a medium through which ideas crystallise into clarity. It's not just about refining thoughts but about sparking new ones, a critical exercise in problem-solving and innovation.

I keep a few things in mind whenever I write. Let's go over them one by one.

You

How do you feel? Are you writing to declutter your head? Are you reacting to something? Are you reflecting on something? Do you feel passionate about the topic (aka strong opinions) or "just have thoughts"?

Writing is art whether you want it or not; art is an expression of freedom. You want to be able to express yourself and nurture ideas. You also want to recognise if you are writing an unsent letter to someone.

Put yourself in a good frame of mind and enjoy the process.

Your Audience

Who is your writing intended for? What do they care about? What problems do they have? Why would they want to read what you write?

Your writing will be different depending on the answers to the questions above. Nothing is groundbreaking here, but it is essential to remember this. Think about explaining what you're currently working on:

• to your colleagues

• to your manager

• to a sales/design/product person at your company

• to your family and friends

It is vital to recognise who you are writing for. You usually know what you want to say but cannot put it into your audience's perspective because you do not understand what they care about. Sometimes, writing is the wrong thing to do before knowing more about your audience.

Format

Are you writing something brief? Are you proposing something? Are you trying to share as much context as you can? Are you trying to communicate a narrative?

The questions above will help you define the tone and volume of your writing. I'll give a few examples:

• To be as efficient as possible with the reader's communication bandwidth, use brief and concise paragraphs that convey information, underline key points, and link to background context ( little-to-no structure, no narrative, intro or conclusion.)

• To propose something new (or change someone's mind), use brief and concise to set the stage, then say what you want to do, then lead to specific actions, and end with the context that has led to those actions.

• To provide full context and information for people without any background in a topic (with a complete narrative structure), starting with why someone should care and background, following with details, metrics, efforts and ending conclusion.

Tools

There is a thing or two to say about writing tools: pen & paper vs your laptop (any digital medium.) You should be aware of how the tools impact you and your writing:

• Pen and paper will enhance cognitive engagement and memory retention. It is slower than typing, making you think and reflect more, producing more nuanced, richer writing. Also, the physical act of writing stimulates brain regions involved in thinking and memory.

• Pen and paper usually reduce the barrier between thought and expression because of the tactile nature of pen and paper.

• When using pen and paper, there are no digital distractions.

• Laptops are ideal for capturing flowing ideas quickly since typing is faster than writing, making them perfect for taking quick notes.

Editing, Revision and Proofreading

You won't nail it on the first pass, and that's okay. Improve it little by little. If you have someone who can provide early feedback and proofread it, that's amazing - take them up on that!

I suggest not overthinking it; writing is subjective and, as I mentioned, is art. Do read On Writing Well, a short read that helped me understand the value of clarity and simplicity in writing.

Hiya everyone!

If you like what you read, please hit that like button, share it, or leave a comment so that the Substack knows to let more people read it. Please suggest a topic for a future essay here!

Share

I have recently read No Death, No Fear by Thich Nhat Hanh (notes after reading.) He was a Buddhist monk and peace activist who significantly influenced Western practices of Buddhism. He was the main inspiration for "engaged Buddhism."

To be clear, I am not religious and will not preach Buddhism to you; it surprised me how many relevant practical things we can draw from Buddhism.

Impermanence

Nothing is permanent in life; the same is true in software. The new code becomes old; the old code gets deleted or rewritten. The line of code you wrote today might be rewritten tomorrow. And that's okay.

We should focus on developing isolated, resilient and adaptable solutions and preparing for the impermanence of technologies, frameworks, and best practices. We should code for obsolescence.

Nothing is Born, Nothing Dies

It is an odd concept on the surface - there is no end and no beginning; there is no birth and death; there is no coming and no going. There is only manifestation - if the conditions are sufficient, things will manifest.

No application or code is truly born or dies; it merely transforms from one state to another — through updates, refactoring, or repurposing. Once you understand that, it can help you approach engineering with a sense of continuity and respect for the "legacy" and "bad" parts of the code. New code is legacy code - a continuation, part of a neverending cycle of change.

If you ask, "But what was before the code existed?" a Buddhist answer will be, "It has always existed; the conditions (business & others) were sufficient for it to appear."

In the same way, we can very tangibly "feel" the presence of people who wrote the code before us (Git history) - they never "die", and they are always with us.

No Self and Interconnectedness

A cloud cannot manifest without water, a tree cannot exist without oxygen, a fire cannot exist without oxygen, and you cannot manifest without your parents, grandparents, great-grandparents, etc. We are all particles from the cosmos, so we are a part of the cosmos. But we are also our own thing.

Software is the same - there is no new code without "legacy code"; no code without a larger ecosystem of software, hardware, users and business, and no code without people.

Understanding the interconnectedness will help you appreciate the broader impact of your work. Understanding the "no self" will help you be an engineer in "your own right" and collaborate and work with others.

Personal Growth and Problem-Solving

Buddhism believes that fanaticism and intolerance create suffering, so it suggests not to be idolatrous about or bound to any doctrine, theory or ideology, even Buddhist ones. They say, "If you get caught in one idea and consider it to be "the truth," then you miss the chance to know the truth."

Approaching problems with an open mind, free from attachment to specific outcomes or technologies, can lead to more creative and effective solutions. Detaching from preconceived notions and fixed ideas can lead to continual learning and personal growth.

Happy Coding! 🧑‍💻

Hiya everyone!

If you like what you read, please hit that like button, share it, or leave a comment so that the Substack knows to let more people read it. Please suggest a topic for a future essay here!

Share

How does one stay productive in an environment filled with interruptions, changing priorities and a constantly evolving technical landscape while feeling rested, sane, "on top of things," and spending time on one's personal life?

Does that sound at all familiar? The higher you go (the more responsibility you take), the more you will have to deal with — the never-ending "scaling yourself" story.

My approach to productivity was straightforward: I will spend more time and energy on a task. While that worked beautifully for me in the short term, it had a not-so-positive, lasting impact on me, both psychological and physical. Two very pronounced things happened:

• I started defining myself through work. Nothing is inherently wrong with that (I enjoy what I do.) The point is any person is so much more than "one something." If you do that, you limit yourself on a psychological level.

• I used to be physically and emotionally drained (this still happens often, but much less than it used to.)

You might read that and say, "Well, Alex, that was stupid." And I agree. Weirdly enough, most of our collective thinking about productivity encourages this behaviour.

Believing In Multitasking

Multitasking, as most people understand it, involves performing multiple tasks simultaneously. However, from a neurological perspective, multitasking is "task-switching." Humans can only focus on one cognitively demanding task at a time. When we think we're multitasking, we're rapidly shifting our focus from one task to another, not processing them simultaneously. This rapid shifting can lead to decreased efficiency and mental fatigue.

There is a limited set of activities where multitasking seems possible, such as walking and breathing. They are so well-learned and automatic that it doesn't require the same cognitive resources as a newer or more complex task.

TL;DR: humans cannot multitask on a biological level.

Maintaining Balance

We seem to perfectly understand that "you need resources to achieve something" in one setting, but it gets lost when we talk about work. Just like a car needs fuel (or a charged battery) to work, you need time to recharge. If you "schedule" work, "schedule" rest & recovery alongside it. Downtime, hobbies, social activities, and moments of solitude must not be an afterthought.

TL;DR: Rest and work must be given equal importance.

You Have Taken On Too Much

I used to have the "hero complex", where I took on too much to "save the day" (frankly, looking for praise.) I lacked the self-awareness to understand that, but it manifested in chronic stress, decreased quality of work, prolonged fatigue, and a sense of being overwhelmed.

TL;DR: Acknowledge that you are overextended. You do not need to do everything.

Busyness

There's a common misconception that being busy equates to being productive. More often than not, busyness is a form of laziness and avoidance.

This illusion of productivity can be seductive because it provides a sense of constant engagement and accomplishment — the "inbox zero" or "no new messages" myth. What do they have in common with slot machines? Random reinforcement. What if there's a new email/message? I must get to zero to be "on top of it."

TL;DR: Do not confuse productivity with "being busy."

Ultimate Productivity System

The ultimate productivity system encompasses four things:

• A "lazy" approach.

• "Signal vs noise" triage.

• Balanced effectiveness & efficiency.

• "Getting things done."

The “implementation” might differ from person to person, but the basis should stay the same.

"Lazy" Approach

The ultimate productivity system is based on a counterintuitive truth: embracing a "lazy" approach can significantly boost your effectiveness. It isn't about shrinking responsibilities but being so efficient and selective in your actions that you maximise results with minimal wasted effort. It's about understanding that "the less you do, the more of it you can do."

"Signal vs Noise" Triage

The ultimate productivity system helps you understand what you should pay attention to and shouldn't and enables you to pay attention to these things.

Do you need to pay attention to Slack? Email? Phone? Set aside the time to check it and let people know you will respond at set times. Minimise distractions as much as you can.

There are two guiding principles I use when it comes to triaging signal and noise:

• I do not want to put energy into things I do not want to do or want more of.

• If it's not helping me to do X, if it's not improving my life somehow, it's mental clutter, and it's out.

Balanced Effectiveness & Efficiency

The ultimate productivity system distinguishes between effectiveness (doing the right things) and efficiency (doing things right.)

It helps you answer questions like:

• What are the N things to get done today, week, month, year?

• Are they the "right" things?

• Am I doing them in the "right" way?

• What can be improved?

• Is rest & work proprotionally balanced?

It helps you maintain a "balanced schedule" and do the right thing:

• Do not schedule meetings back-to-back; give yourself a 15-minute break in between.

• Go to the gym, walk, hang out with your friends, and do nothing for an hour after work to decompress.

• Go on a holiday once a quarter because it helps you maintain your work/life pace.

Getting Things Done

The ultimate productivity system helps you get things done by focusing on pre-defined work using personal sprints (the famous Pomodoro technique) and triaging urgent work by using the following categories:

• Do it now.

• Decide when to do it.

• Delegate it.

• Drop it.

Your productivity system might be different from the next person, but it must enable you to do more of what you need/want to do. It will require ongoing adjustment and commitment. I’ll describe my implementation in a later blog post.

Hiya everyone!

If you like what you read, please hit that like button, share it, or leave a comment so that the Substack knows to let more people read it. Please suggest a topic for a future essay here!

Share

We become what we behold. We shape our tools and then our tools shape us

- Father John Culkin

I’m keeping things light this week with a list of tools and services I use daily.

• Calendar. I have tried several calendar apps: Cron (Notion Calendar), Amie and Rise. I use Amie regularly now. They have also blended the email, to-do and calendar together. I do not blend them the same way (I do not find it helpful); maybe I should! I have yet to try Hey Calendar.

• To-do: I have been using Things for a long time. I put all that I need to do in there, assign the date, and never think of it again until the said date. Such a great app!

• Notes: I use Obsidian for electronic notes (I wrote a post about taking notes.) For everything else (during meetings or when I need time to think and reflect), I use Baronfig Notebook and Muji pens.

• Journaling: Something that I have started doing recently regularly. I primarily use DayOne; just started playing around with Journal and Pile.

• Video & Screenshots: I use CleanShot (screenshots and voice-less recordings) and Loom (short educational videos.) Both are amazing.

• Email: I use Superhuman. $30/month is very expensive. I have not found an email client I enjoy using, so I keep returning. I have tried Hey, but have not considered switching.

• People: I use Clay to keep in touch with people and be more thoughtful about my relationships.

• Command Switcher: I switched to Raycast from Alfred a few years ago and never looked back. I rarely touch the trackpad and do everything through Raycast.

• Password Management: I have been a 1Password user for as long as I can remember. I am not the biggest fan of their latest UI, but a big fan of the service.

• Diagrams: I create all diagrams in Figma, a habit I picked up while learning Figma to work better with designers.

• Browser: I started using Arc while it was still in beta and never looked back. A much better experience than Chrome with familiar DevTools.

• Terminal: I have been using iTerm2 for years until Alacritty came out. The performance is what made me switch.

• Git: I use the Git command line tool to work with the code. I sometimes need to look at a big diff, and that’s when Fork comes in handy. Very fast, great UI. One of the best $50 I have spent.

• Diffs: I use Kaleidoscope for Git (merge conflicts), text, image, and folder changes.

• Text editors: I primarily use NeoVim (an old habit which warrants a separate story.) When I explore code, I use VSCode or GoLand. I have played around with Zed and Fleet.

• Databases: I have been using TablePlus before I found DataGrip. Both are great; I am gravitating towards DataGrip, though.

If you like what you read, please hit that like button, share it, or leave a comment so that the Substack knows to let more people read it. Please suggest a topic for a future essay here!

Share

People occasionally ask me to recommend books to help their professional career development. I can usually come up with two or three books on the spot, but I always forget a few good ones. I hope this post can serve as a record of books I have read that affected my thinking about software engineering: some of the general purpose, leadership and management.

Books that I would recommend reading:

1. Four Thousand Weeks: Time Management for Mortals by Oliver Burkeman. When you realise the average human life span is only 4000 weeks, it makes you rethink your daily life.

2. The Making of Prince of Persia by Jordan Mechner. It was the first computer game I ever played. It was a great read; it put many things in perspective. I wrote some notes here.

3. The Mythical Man-Month by Frederick Brooks Jr. This is the first professional book I have read.

4. Refactoring: Improving the Design of Existing Code by Martin Fowler. Why you should refactor, how to recognise code that needs refactoring, and how to actually do it successfully, no matter what language you use.

5. On Writing Well by William Zinsser. Sound advice for anybody who wants to learn how to write or who needs to do some writing to get through the day. Writing is especially beneficial as you move up the engineering ladder.

6. Meditations by Marcus Aurelius. Stoicism offers a practical, logical approach to day-to-day life. The advice is simple but has implications across the board.

7. Switch by Chip Heath and Dan Heath. The rational mind and the emotional mind, where they clash and what to do about that. It added another dimension to human nature and helped me “deal with politics.”

8. No Death, No Fear by Thich Nhat Hanh. I enjoyed it because it made me think about the “accepted” concepts of death, fear, and existence. He nudges you to think about how we live and die differently.

9. An Astronaut’s Guide to Life on Earth by Chris Hadfield. Some advice is counterintuitive (don't visualise success, care what others think, and always sweat the small stuff) but has merit!

10. How To Live by Derek Sivers. A short read and has a weird format and actionable directives.

Books that I picked a few valuable things from:

1. High Output Management by Andy Grove. It is considered a classic, but some of it is starting to feel a little dated, so read it with that in mind and take away parts that feel authentic to you.

2. The Manager's Path by Camille Fournier. A short read for technical managers which explores the engineering manager role and covers mentorship, leading teams and overcoming obstacles.

3. Neuromancer by William Gibson. Without spoiling too much, he imagined a dystopian but realistic AI future.

4. The Lion Tracker's Guide to Life by Boyd Varty. I wrote some notes here.

5. Crystallising Public Opinion by Edward Bernays. The father of propaganda, the man who convinced the USA that eggs and bacon are great breakfast, the story-teller.

6. The Alliance by Reid Hoffman. I read it while working at LinkedIn: a founder’s take on how to treat employees - as allies.

7. Hard Things About Hard Things by Ben Horowitz. If you enjoy rap and older stories about business, it’s a great book.

8. The Culture Code by Daniel Coyle. A good overview of what makes organisations successful.

9. Radical Candor by Kim Scott. How to be kind and clear simultaneously and effectively give constructive feedback.

10. Stealing the Corner Office by Brendan Reid. Short read and practical advice on how to approach “politics.”

11. Managing Oneself by Peter Drucker. A bit dated, but still relevant, IMO. You must carve out your place in the world and know when to change course to keep yourself engaged and have a successful career.

12. The Scout Mindset by Julia Galef. We are driven to defend the ideas we most want to believe. But if we want to get things right more often, we should go out, survey the territory, and come back with as accurate a map as possible (like a scout.)

13. Staff Engineer by Will Larson. A great set of interviews and stories and an overview of how broad the “Staff Engineer” role might be.

14. Crucial Conversations by Kerry Patterson and Joseph Grenny. How do you turn a contentious conversation with anger and hurt feelings into a productive one?

In the queue:

1. Good Strategy, Bad Strategy by Richar Rumelt.

2. The Five Dysfunctions of a Team by Patrick Lencioni.

3. Crossing the Chasm by Geoffrey Moore.

4. The First 90 Days by Michael Watkins.

I’ll keep updating the list.

Happy reading!

Hiya everyone!

If you like what you read, please hit that like button, share it, or leave a comment so that the Substack knows to let more people read it. Please suggest a topic for a future essay here!

Share

For most of my professional career, I have been writing JavaScript. If someone had told me that when I was in uni (or to one of my professors), we’d all collectively laughed that person out of the room. JavaScript was not considered a “real language” for a long time. And, indeed, you could toy around with a few things on the web, but you couldn’t deliver a fully working website: you would use PHP for that.

Two or three years in (after I moved to the US), I found out I liked putting things in front of the users and seeing their reactions (that’s how I ended up working on consumer apps.) How did I find that out?

Read more

Hiya everyone!

If you like what you read, please hit that like button, share it, or leave a comment so that the Substack knows to let more people read it. Please suggest a topic for a future essay here!

Share

Here’s a relatively simple but effective troubleshooting technique: whenever faced with a complex problem, start breaking it down by asking straightforward yes or no questions.

Here’s a contrived example: imagine you’re working on a feature that’s supposed to integrate with an external API, but it’s acting up. Is the API key correct? Yes. Is the network connection stable? Yes. Is this the right API endpoint? Yes. Are the correct headers passed through? No.

This method isn’t just about solving problems; it’s a mindset shift. You narrow your focus from an overwhelming array of possibilities to specific areas. You feel like you make tangible progress towards solving a problem by continually answering the questions and narrowing the problem down further. As a result, you will have a list of bite-sized, manageable tasks by the end of the exercise.

The beauty of this method is that it can applied to any problem.

Happy troubleshooting!

Subscribe now

Hiya everyone!

If you like what you read, please hit that like button, share it, or leave a comment so that the Substack knows to let more people read it. Please suggest a topic for a future essay here!

Share

This is Engineering Career Growth, a newsletter with lessons, stories and, hopefully, some wisdom about a career path in software engineering.

My name is Alex Navasardyan. I am a Senior Staff Software Engineer at Auditboard. I have been doing software engineering for 15 years, made mistakes, and had some successes. Reflecting on my career path, I see that few "career in software engineering" materials were available (compared to what you can find now.) Even now, the subject is still complex to navigate with all the information on Twitter and YouTube.

My career path was far from straightforward - I wrote a lengthy note about it.

I wish someone had explained how to have a successful career and enjoy life at a slightly different pace back then: work responsibly and develop interests outside of work. It is great to be able to sprint sometimes, but you have to sprint to something. Sprinting for the sake of being ahead is pointless? When do you stop?

This newsletter is right for anyone who wants to learn and grow their career, whether you're just starting out or ready to take your career to the next level.

• Students or recent college grads.

• Aspiring/junior software engineers.

• Senior and Staff software engineers.

• Software engineers who are looking to become engineering managers.

• Engineering managers.

In this newsletter, I’ll share the important lessons I’ve learned in my career, stories, anecdotes and the things I am still figuring out.

Let's be friends on the internet. I am on X, Github and LinkedIn.

Subscribe now