bwh2

Two good ones: 1) Where Wizards Stay Up Late and 2) How the Internet Happened: From Netscape to the iPhone

The primary cost differences I have experienced come with maintenance and fees, not the initial build.

Maintenance = iOS version updates, dependency upgrades, App Store requirement changes, etc. have been costlier and more out of your control than with web apps. Fees = the App Store's 15-30% fee is more expensive than using a web payment processor.

I highly recommend the book System Design Interview by Alex Xu.

Although you wouldn't expect it, the book Monolith to Microservices presents solid arguments against microservices. The author cautions against using microservices throughout the book due to the additional complexity introduced.

Difficult Conversations. So much stress and anxiety comes from anticipating, avoiding, or not knowing how to have difficult conversations.

It sounds like retention is your problem, less so acquisition. Have you talked with customers to understand why they are leaving your product?

Agreed. That was the point of my comment - there is an abundance of developers who just work in JS/TS/React and have not picked up new technologies. Adding C#, Java, SQL, etc. helps your marketability.

It would help both in demonstration of interest in learning that language further and in being able to pass technical interviews.

As a hiring manager who looks at a lot of resumes, I think your hunch is correct. I see a lot of junior to mid-level developers that primarily work in JS/TS/React. That market is heavily saturated and I regularly read posts on LinkedIn from these people about how difficult it is to find a job.

The candidates that stand out from the pack are those with some tangible production backend experience in languages like C#, Java, etc., combined with SQL experience. Strictly in terms of marketability, I do believe getting real-world backend experience greatly increases your value.

Similar size company and over the past 2y we transitioned from technology based teams to stream-aligned teams that include engineering, product, and design within each team. The book Team Topologies is a good reference for this and fairly quick read.

In my experience, the pros of stream-aligned teams vastly outweigh the cons. The major pros are reduced cross-team dependencies and fewer hand-offs, more ownership over work, focusing people on a narrower set of customer/business problems, and that stream-aligned teams are easier to refactor and decompose as the organization grows.

What I learned along the way is that you will still have some cross-team dependencies based on technical expertise. So you will benefit from your engineering leaders explicitly and regularly discussing these needs, then incorporating some resource sharing into their plans. For instance, you might have an engineer who really knows one area of the product or technology brought into another team's kickoffs and design reviews or even joining the other team temporarily.

Consider focusing on managing the team through this: "there are a lot of skeletons in the code & infra to worry about." Sometimes what happens is you have seniors who know the technology and product inside and out, but don't think in terms of team dynamics and the organization's ability to deliver effectively.

A few books that influenced my product thinking: The Cold Start Problem, Working Backwards, and Strategy Rules.

Most people have not developed the habits and discipline necessary to benefit from a plan.

These are both well written and happen to be about writing: On Writing Well by William Zinsser and On Writing by Stephen King.

The Five Dysfunctions of a Team is similar in style and a good read.

Difficult Conversations

Some of my favorite books around managing software projects and technical leadership:

    * The Manager's Path - read the chapter on being a Tech Lead
    * Making Work Visible
    * Accelerate

The Cold Start Problem and Matchmakers are two good books about marketplace dynamics.

Focus on naming accuracy. Clear thinking is often apparent in how variables and methods are named.

A few books that I enjoyed:

  * How the Internet Happened: From Netscape to the iPhone
  * Where Wizards Stay Up Late: The Origins of the Internet
  * Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture

A few books that are relevant to your situation:

  * High Growth Handbook - covering the operations and biz side
  * The DevOps Handbook - developer effectiveness in larger orgs with examples
  * Monolith to Microservices - how to execute the transition
  * Team Topologies - how to organize teams for effectiveness

Drift Into Failure is a good read about how systems fail, albeit a little light on solutions.

TrainingPeaks | Colorado or Remote in USA | Full-time

  * Software Engineer (0-2y experience)
  * Senior Software Engineer (+4y experience)

https://trainingpeaks.com/careers/engineering/

I have a big list on my website at https://www.briansnotes.io/books/ but here are a few:

  * The DevOps Handbook - Lots of tactics for improving the productivity and effectiveness of engineering teams
  * Extreme Programming Explained - Solid guide to agile ideas
  * Staff Engineer and The Manager's Path - Helps you understand your career path and the expectations that come with positions like Tech Lead, Staff Engineer, Engineering Manager, etc.

I live and hire people in Colorado, and a bunch of recruiters contact me about remote roles. Most companies that fear transparency just advertise very broad ranges, e.g. $100-200k. I'm sure some companies refuse Colorado employees, but nobody I've talked to seems concerned.

The market for engineers in Colorado is very hot. What we're seeing is the smaller Boulder/Denver startup scene from the past decade transforming into a larger and more stable market as companies like Ibotta, Guild Education, SendGrid, etc. are hiring a ton of engineers. And you still have lots of smaller startups competing for talent.

Physical book, highlighter, and pen for taking notes in the margin.

Two books:

* The INTP: Personality, Careers, Relationships, & the Quest for Truth and Meaning. This book helped me understand my own journey in life.

* How to Win Friends and Influence People. A little cliche, but reading this book drove me to reflect on what a pedantic jerk I was being sometimes.

Read Peopleware. Right now you're focused on mechanics like standups and retros, but for those to be effective you'll need to really grasp underlying principles.

As for career path, read The Manager's Path.

The book System Design Interview is quite good and pragmatic. Personally, I found Designing Data-Intensive Applications less useful because it works on a much lower level. Like if you want to know how database internals work, then read DDIA. If you want to understand how to author a scalable API with layers of caching and distributed data storage, read SDI.

Read The E-Myth Revisited to really understand the difference between working on the business and working in the business.