Hacker News new | past | comments | ask | show | jobs | submit login
Classic books for tech leads or those aspiring to be (sourcelevel.io)
210 points by bmgoss on Aug 11, 2020 | hide | past | favorite | 54 comments



I don't know if it's a good list for tech leads, wannabe or otherwise, but one could do worse in choosing three books.

I do take issue with the the Mythical Man Month blurb, though. My copy has disappeared from my bookshelf again, but IIRC the "adding more people makes it later" bit was just one of many essays in that book, but it's the only one people ever mention. But it's the one that allows us all to pretend we read it. Quick quiz, hot shot: what did you think of the surgery team metaphor? Another thing few mention about MMM: at least some parts are noticeably dated. (But without a copy in front of me, I don't recall which parts.) So, good book that we probably all should actually read instead of just spouting about nine pregnant women, but not all of it will be relevant today.


I really think that the Sharp Tools essay is pretty significant. That's an initiative that I'm really trying to push at my work. In the one essay about how adding people can make a project even more late... I think too few people focus on the significance of partionable tasks -- that is, when you're a tech lead, it's very important to understand what tasks should or should not be partitioned, and equally as important, _how_. For example: If you need two long ditches dug and have 2 workers - you might say "you dig ditch A, and you dig B". Or you might say "You start at the north end of A and you at the sound end -- dig towards each other and meet in the middle. Then, repeat for ditch B" But you would NEVER say "You dig the top half of ditch A, and you dig the bottom half, meet in the middle, and repeat for ditch B". Not enough managers/leaders put an emphasis/importance on understanding how to partition a task -- or that it often requires more than MBA knowledge to do so.


Depends on the ditch. That's effectively how the Loon Lake Powerhouse was constructed. Traversing the entrance shaft funicular you can see the bobble where the upper and lower "ditches" deviated somewhat.

Upper American River Project, east of Sacramento.

https://en.wikipedia.org/wiki/Upper_American_River_Project

Video tour:

https://youtube.com/watch?v=LHYnxvp-hJY


Brook's law is also outdated. It's mostly only relevant for when you deliver your software with a forklift.

Even Steve McConnell of Code Complete and Rapid Development has argued against it:

https://stevemcconnell.com/articles/brooks-law-repealed/


> Brook's law is also outdated. It's mostly only relevant for when you deliver your software with a forklift.

Hmm... not sure I agree with this. A few points come to mind:

- Some portions of a project become hotspots at different times and have a natural code concurrency limit (it may not be 1, but certainly 10 people can't make changes to the same class or other critical code path concurrently)

- Onboarding is a real thing. It requires current staff to train newcomers, at the very least. At worst, they have to account for the newcomer's coding/architectural misses

- Communication and consensus building with more folks takes exponentially more time (or is it combinatorial, I can't keep that straight).


In a SaaS world the value stream is broken up and delivered as appropriate. What does it mean for a project to be late if there is a value stream constantly being delivered?

Onboarding is a real thing but Brook's calculations are absurd by today's standards. 1 Month to onboard someone? We have developers committing code in their first week. Sometimes day 1 or 2.

Read McConnell's essay. It's v. good.


At Google, engineers start committing code in their first week too.

That doesn't mean they're fully on-boarded until 6 months in.


I was on a project where we added 6 people to an 8 person team in 2 weeks. Velocity stayed exactly the same as before for a sprint or two but quality issues jumped. We then spent an enormous portion of time on bug fixing. It took about 2 months before the overall team really saw a net benefit to velocity by adding those people.

Brooks exact numbers might be come from a different time, but the principle holds unless you have an uncommonly decoupled set of problems.


> We have developers committing code in their first week. Sometimes day 1 or 2.

If you're doing anything complex (which can just be: if your codebase is more than a year or so old) than the quality and velocity of code someone can contribute on day 1 is vastly lower than they can a month later.

I see the Mythical Man Month tossed around as an excuse for not trying sometimes - by people who haven't even tried to split up and spread out chunks of work in parallel - but onboarding cost is definitely real.

You gotta evaluate "can I get enough overall throughput at this point in time to make up for the total efficiency lost" and also the rest of the business priorities outside of this one project.


Microservices are all about trying to get around Brook's law. It is very much still in force.


> Quick quiz, hot shot: what did you think of the surgery team metaphor?

Interesting side discussion -- I have just started reading the book, but I did think that the idea of the surgical team was an interesting and radical departure from the standard "two-pizza team" pattern of a few developers that are considered roughly equivalent aside from minor leveling changes. My personal thoughts were that it would be hard to see success with the model unless you made sure all the roles were recognized as being equally important towards the success of the team.

I had wondered about (and rour comment inspired me to look up) whether people have had any experience trying it out, https://softwareengineering.stackexchange.com/questions/3552... has some interesting references and pitfalls of the approach.


The best of Brooks is the silver bullet article. It was included in newer editor editions of the book. Great to understand why the shiny new visual programming product someone is trying to sell your company won't improve your productivity


I was quite sad the first time I brought up the surgery team metaphor with my surgeon friend and she said that's not how it works at all.


> the "adding more people makes it later" bit was just one of many essays in that book, but it's the only one people ever mention

The reason it is continually mentioned is companies make this mistake over and over and over again. I am witnessing it happen right now on a project, and I have seen it happen many times before.


It’s been at least a decade since I read it, but isn’t there a whole chapter on using a mouse AND a keyboard to increase productivity? :D

So yeah, some of it has dated, and some of it I disagree with, but it kills me that a lot of the lessons are still not learnt 45 years later.


The concept that a complete document/tested/integrated product system takes much more work that the base product is also a good one.

That said, I'm not sure I'd recommend the whole book today.

Might also include Soul of a New Machine and Showstopper!


I vaguely recall reading Soul of a New Machine years ago, but I don't recall there being a lot of SWE lessons in it. Maybe it was because I read it so long ago. Mind sharing a few things you got from this book?


It's been a long time since I read it as well and I knew the hardware/microcode people in the book better than the OS folks--and I think the book probably focused on them more. Maybe it's not really SWE lessons per se as so much as just a really good account of a computer systems project. (I worked at Data General for many years though I joined a few years after the events of the book.)

Showstopper (about the development of Windows NT) is more focused on software obviously.


The greatest lesson I took from the book was "no mode switch".

This is an excellent principle for software development as well IMO.


Now, I love the story about the biblical quantities of paper documentation that was produced, distributed, and consulted every single day during the development of OS/360. But broadly the book has aged poorly -- it's quite thoroughly misogynistic for example -- and absolutely does not get a pass since the author explicitly declined the opportunity to update it in later editions. Moreover, the writing is nothing special, and the ideas have seeped quite deeply into our culture, so it's not necessary to read the primary source. Folks today would be better off reading the Wikipedia page which does cover the main concepts, including the surgical team.


"Misogynistic" how exactly? I've seen people call it misogynistic because it introduced the term "man-month", so forgive my skepticism.


I've put together a reading list for VPs of Product here, which is pretty analogous to the tech lead concept but for PMs:

https://staysaasy.com/product/2020/06/14/a-vp-products-readi...

(edit: we write stuff for engineers too)


it seems like "tech lead" is a position with responsibility but no real authority, a sort-of middle manager. i'm sure the books are good, but the thing I'd want help with is how to achieve a balance between ensuring the team is delivering good work (in a technical sense) while making sure the people above you on the food chain - those with actual power - are kept happy.


I feel like "tech lead" also varies so much from company to company. Where I work, people are technically bestowed the title of "tech lead," and this just means they have to take ownership of far more work for essentially no more pay.

Most "tech leads" where I work are senior engineers, but not all senior engineers are "tech leads." Here, it seems more like a purgatory positions where you don't want or have the skillset required for engineering management, but are far more senior than other senior engineers.


I usually see it as “most senior person with responsibility for this domain” which, if it’s a smaller / less intense domain, may not be that senior at all.


Well you can set standards, if you're the picky type you can then say how you want things done.

I am often less picky than other people, but I find that the picky types often want things that I feel are less than optimal.

So getting offered tech lead coming into a place can be seen as a good defensive choice if you are coming from a place where you feel like you've been suffering because you didn't have the control.


Power comes from:

a) coworkers respect your competence & judgement so they align with your decisions on technical matters

b) engineering manager believes what you have to say about what the project needs, which may include staff allocation & performance management


Sounds like you've never worked at a startup where the CEO walks in one day and says "we're changing direction" everyone stops what they're doing and desperately tries to turn the boat around, only to have that happen again two week later...

Like it or not, that is what power is.

Building respect and trust is great, but you can have all of these things and not have any real power. I've seen trusted respected people let go in a heartbeat when times are tough. The people that can decide to 'let people go' are the ones with power.

In my experience tech leads and middle managers often have to do the difficult task of balancing the whims of power with sound technical decisions. This is a hard task because it's frankly much easier to just bow to the whims of leadership and wait for the day when they decide a "shakeup" is needed and layoff most of middle management.


I mean that's not really power if your staff quits on you after you do that. If you want to be able to pull off those sorts of pivots successfully, you need your coworkers to respect your competence and judgement.


If you don’t trust or respect the CEO you leave.

Could any other CEO have come into Apple in 1997 and done what Jobs did? They respected Jobs more than they would have a generic CEO.

Heck didn’t the Pandora CEO convince people to work for two years with no pay?

A number of us stayed at a startup until the bitter end because the leadership was completely honest with us and the investors promised to pay us for every hour we worked.


And therefore not from a "tech lead" title.

Edit: I'm saying this because I decided to stop being "tech lead" recently, precisely because of the problem of responsibility without authority.

Yes, people respect me and my decisions, up to a point (we have several very competent people and we don't always all agree) . They did that before I was tech lead and to the exact same amount after. My work did not change one iota compared to what I was doing before. But suddenly I got blamed for some things that I had no power to prevent.

That's just not healthy.


> those with actual power

The power that comes with a job title or position is actually quite limited. And it also calls into question as what exactly is meant by power. Personal power (getting your way?) or creative power (putting forth your energy for the benefit of the organization). I find that it's actually not too hard to have a great deal of creative power, regardless of personal power -- by listening and responding well to the needs of others and by effectively solving problems.


It is ever possible to have real power as an (non-executive non-shareholding) employee of an organisation?


Power implies the ability to cause change. When you say "real" power I think you might have some specific kind of change in mind. What kind of organizational influence are you considering "real" power?


Why not? The only "problem" is that everyone who actually goes down that path becomes a manager or executive given enough time.


It doesn't matter where you are in the org chart. Being a good leader is about prestige and respect, not dictatorial power.

With prestige comes attention to what you say and do, and ability to influence decisions.

If you feel like the middle manager is powerless, these are exactly the types of books to read. Other recommendations include High Output Management, Drive, How To Talk So Kids Will Listen (I'm serious), Turn the Ship Around, Out of the Crisis, and more.


Which Drive book are you talking about? who's the author? Those books you mentioned seems interesting, I'll check out. If you have more on topic that you think are also worth recommend, please let me know.


"Drive" is by Daniel Pink, and it's about what really motivates problem solvers/intelligence workers.


thanks


That’s something I have learned early in my career. No one will “give” you authority. You have to create your own role through trust and leading by example.


Authority is not equal to power.

Classic management theory is that their are three levers of power in an organization - relationship, expert, and role in that order.

No one is going to go the extra mile for a leader they don’t like or one they think is an idiot. Role power is the least effective.

I’ve left plenty of jobs because of a reorganization put me under a lead/manager that I didn’t like or respect or I thought they were an idiot.

Even if you don’t leave a company because they lean on their role power too much, people will “work to rule”.

I’ve had a lot more influence working at small companies by building relationships and demonstrating expertise.


Having read peopleware, that’s effectively what it is about.


This is the must read book on making functional orgs.


This description sounds more like a product manager and this is essentially how I see Tech Leads in my department. This makes them really think hard about their responsibilities and the actual job, that needs to be done.



These are nice books, but I don't believe in a technical manager list without Jerry Weinberg's books: https://leanpub.com/b/peopleskillssoftbutdifficult


Here are my three:

"Unwritten Laws of Engineering" https://www.amazon.com/dp/0791801624

Originally meant for mechanical engineers, it provides specific and general non-technical career advice. It focuses on what we call “soft” skills today. This field puts so much weight into technical prowess that we often think of these “soft” skills as somehow beneath the “hard” skills. Nothing could be further from the truth. If you don’t spend time on learning how to navigate your career, you’ll be as well off as a dragster on the backroads: you’ll get nowhere fast. I only wish I could have read this book sooner; it would’ve saved me a lot of trouble early on.

"Becoming a Technical Leader" https://www.amazon.com/dp/0932633021

Don’t let the title fool you: this is not just for people planning on becoming a “Tech Lead.” It’s for anyone in the tech field, period. If you pickup this book you must work through the exercises to get the full effect. It will be worth it. It’ll be like having your own therapist, life coach, and mentor, except that it’s just you and a notebook answering very important questions.

"The Pragmatic Programmer" https://www.amazon.com/dp/020161622X

I consider this book 10x better than Clean Code and Code Complete combined! (Though that may just be because I read PragProg first?) As the name suggests, this book provides more tactics advice but also gives great career advice too. The most famous is to “learn a new language each year.” This kind of advice seems a bit much, but over my career I’ve had to write in over a dozen different languages, even though 90% of the code I’ve written has been in just one language, the ability to pickup new languages quickly and easily is a solid skill to have. And that’s just one particular tip from this book.

(These are excerpts from my suggested reads blog post: https://valbaca.com/posts/my-suggested-reads-3cie)


A grasp of organisational theory, its history, and observed realities is also recommended.

Charles Perrow, Complex Organizations is both a classic and review of previous literature (through about 1985):

https://www.worldcat.org/title/complex-organizations-a-criti...

Though it makes little discussion of the high-tech world, I read its observations on the music industry from ~1940--1980 as highly similar. Labels are largely analagous to VC (including YC), and the disruptions of new trends and technologies, and re-forming of controlling monopolies, strikingly similar.


This article has so many omitted words that it’s hard to follow, even if the content is decent. I’m left wondering - did the author ever actually read what they wrote, or did they just press send and hope for the best.


Don't want to be too negative but there's a decent amount of politics that you're required to navigate to get their and then handle, wish someone would write a guide for that, dead serious


If it helps anybody, this is what I learned from my time at G.

Suppose you are given an objective. Now you drive a project to achieve said objective. For starters:

0. Identify project requirements and scope.

1. Identify stakeholders. These are people/team who are directly/indirectly affected by your project/decisions. They are also people who may have nothing to do with your project, but could stand to gain something from working with you.

2. Talk to said stakeholders. Find out what they are good at, what they want and need. The underlying driving motivation for everyone is almost always career progression (promotion/bonus/etc), but this translates to different interests and goals. E.g our team just built this new tool and we want it to be adopted more widely in the company for greater impact to show that we're worthy of promotion to the next level.

3. Now that you have identified people's roles and interests, it's time to figure out how to align your interests with theirs. For example, you're migrating off a deprecated framework/tool, and another team is peddling their new framework/tool. Maybe you use their framework/tool. Maybe they customize it for you. Maximize this alignment. Business people would call this synergy.

4. Consulting with people shows that you are not a lone wolf, that you can work with others, plus no single person holds the entire picture along with the details. One added benefit is people feel good when they're consulted with. Makes them feel important. It also gives you visibility amongst upper leadership. This step is to build support for and awareness of your project. When everyone has a hand in it (no matter how small), they'll care more that it succeeds.

5. You get back to the drawing board and start designing the system/solution. You hold regular meetings with stakeholders to keep them in the loop, and to incorporate their suggestions. Any time there's a blocker or consensus can't be achieved, you go to their manager directly, or you have your manager talk to their manager. This is the diplomacy/politics part, and where great soft skill is needed (you can leave it to your manager as well). Ideally, if you did a good job with step 3 and 4, you won't have to get into this quagmire.

6. You partition work and dole them out to junior engineers, preferably pieces that can help them in their career as well. This is mentorship + delegation. It's what allows you to be productive and effective - you leverage other peoples' skills.

7. When you finally launch, thank and credit everyone involved (including leadership). Everybody gets to look good.


I am an engineer that works as a civil servant. When I first encountered politics (both office and "real") I started reading political philosophy, rethorics and sociology books. Pretty broad theme. I know.

My biggest takeaway was a framework for explaining my reality. To be specific. I now view some interactions though a perspective of "power".

I don't know if it helps me navigate the interactions better. But my emotional well being is much better.


I agree with this. Eager to hear advice / tips / book suggestions on how to deftly navigate this without explicitly appearing political to the rest of the team?


Joel on Software - practical advice for both the leader and the developer. I still reference it frequently.

Edit - more explanation




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: