[HN Gopher] Ask HN: Reading material on how to be a better softw...
___________________________________________________________________
Ask HN: Reading material on how to be a better software engineer?
I've gotten to be quite good at the actual coding part after a
decade or so of programming. I'm not looking for better code
practices, although I'll obviously still learn and grow there.
What I'm seeking is reading material regarding how to manage
project scope, be better team member, converting asks to
deliverables, managing expectations from management, enabling team
members by opening communication channels across teams, time
management, etc. Any suggested reading material? Preferably books,
but excellent blog posts are welcome.
Author : OneOffAsk
Score : 196 points
Date : 2022-12-04 16:03 UTC (6 hours ago)
| ljf wrote:
| I loved 'Joel on Software' - I got a heap from it (I was a PO but
| attempted to be as technically aware as possible).
|
| Taught me so much about all the things you mentioned
| black_13 wrote:
| turtledragonfly wrote:
| This is more on the "managing lots of code" rather than the
| people side of things, but: John Lakos has a book called "Large-
| scale C++, volume I: Process and Architecture."
|
| Even if you don't read the book, I think this talk he gave on it
| is a good watch: https://www.youtube.com/watch?v=4NvRnkz6jVM
| antipaul wrote:
| The Missing Readme" book seems right up your alley
|
| https://nostarch.com/missing-readme
|
| "The Missing README fills in that gap--a distillation of
| workplace lessons, best practices, and engineering fundamentals
| that the authors have taught rookie developers at top companies
| for more than a decade"
|
| Get it just for the "Design Doc" template!
| _dain_ wrote:
| seconding this, very high signal-noise ratio.
| pjmorris wrote:
| 'Becoming A Technical Leader', Gerald Weinberg. Jerry, working
| for IBM, designed the telemetry system NASA used to track early
| manned space flights and then spent a career helping
| organizations, teams, and people achieve their goals, both
| technical and personal. He wrote many books on the topics you
| mention, all of them worthwhile. I picked this one as a place to
| start.
|
| 'Making Things Happen', Scott Berkun. Berkun was a successful
| developer and product manager at Microsoft and the book captures
| his reflections and research on project management.
| mystickphoenix wrote:
| A few things come to mind along with what's already been
| mentioned:
|
| Assorted Non-Book Readings:
|
| - https://randsinrepose.com/dont-skip-this/
|
| - http://www.stilldrinking.org/programming-sucks
|
| - https://sysadvent.blogspot.com/2019/12/day-21-being-kind-to-...
|
| - https://donellameadows.org/archives/leverage-points-places-t...
|
| - https://grugbrain.dev/
|
| - https://changelog.com/posts/rich-hickeys-greatest-hits
|
| - https://github.com/papers-we-love/papers-we-love/blob/master...
|
| - http://www.cs.unc.edu/techreports/86-020.pdf
|
| Books:
|
| - The Phoenix Project: Gene Kim, Kevin Behr, George Spafford
|
| - Deep Work: Cal Newport
|
| - The Art of Leadership: Michael Lopp (Rands)
|
| - Extreme Ownership: Jocko Willink and Leif Babin (once you get
| through the ho-rah stuff it's a fantastic read)
|
| - Time Management for System Administrators: O'Reilly (fantastic
| for interrupt driven work)
|
| - Elements of Clojure: Zachary Tellman (not just for Clojure
| devs)
| LanternLight83 wrote:
| I checked out your other links because you included Programming
| Sucks; not because it's an _amazing_ resource, but because my
| partner and I once nearly died of laughter listening to the
| audio book rendition at the bottom of a page. Grub doesn 't
| disappoint either, but is still recent enough to be the wider
| HN consciousness.
| [deleted]
| cauthon wrote:
| A Philosophy of Software Design by John Ousterhout is good
| reading
| [deleted]
| rglover wrote:
| Systemantics is a fun read: https://www.amazon.com/SYSTEMANTICS-
| SYSTEMS-BIBLE-John-Gall-...
| la_fayette wrote:
| Elicitating the real needs of customers is the most challenging
| part for me within a software development process. The concept of
| Domain Driven Design (book by Eric Evan) helped me a lot to
| decode the language of the customer and transform it into an
| object model.
| allenleein wrote:
| SICP (Structure and Interpretation of Computer Programs)
|
| https://web.mit.edu/6.001/6.037/sicp.pdf
| medler wrote:
| The Unwritten Laws of Engineering by WJ King is a great book on
| the people-skills side of engineering and management. At ~60
| pages it's also mercifully short and to the point.
| jll29 wrote:
| > Ask HN: Reading material on how to be a better software
| engineer?
|
| That's a bit like "Ask HN: Reading material on how to be a better
| pianist?"
|
| You will need to write and maintain a lot of code, and make a lot
| of mistakes, then you will get gradually better.
| squeegee_scream wrote:
| Will Larson's An Elegant Puzzle https://lethain.com/elegant-
| puzzle/. It is mostly or entirely taken from his blog so you can
| just read the blog for free but I find the book valuable
| jdougan wrote:
| "Death March", by Ed Yourdon. Most of the reccommended books In
| this thread are about trying to keep a project in a good place.
| This book is about what to do when it has already gone wrong. You
| can make a not terrible argument that much of the industry has
| gone to an all-death-march-all-the-time model. This book can
| help.
| [deleted]
| dunk010 wrote:
| The Design of Design.
| vl wrote:
| _Peopleware_ and _Mythical Man-Month_ are fundamental to
| understanding larger software projects and teams.
|
| They often state obvious things, but I didn't guess them myself.
|
| _Mythical Man-Month_ also provides important historical
| perspective.
| mooreds wrote:
| Hiya,
|
| I'd consider these books/articles/podcasts:
|
| * Secrets of Consulting by Gerald Weinberg:
| http://geraldmweinberg.com/Site/Consulting_Secrets.html Every
| problem is a people problem.
|
| * Refactoring by Martin Fowler et. al:
| https://martinfowler.com/books/refactoring.html talks about how
| and why to refactor, as well as providing a nomenclature for the
| process.
|
| * Code Complete by Steve McConnell.
| https://stevemcconnell.com/books/ A bit dated (the last version I
| could find was from 2004) but a great overview of the entire
| software process, from requirements to maintenance.
|
| * The Mythical Man-Month by Fred Brookes:
| https://www.oreilly.com/library/view/mythical-man-month-the/...
| best practices about software development, written about a
| project from the 1960 and 1970s.
|
| * The Joel On Software Strategy Letters:
| https://www.joelonsoftware.com/2000/05/12/strategy-letter-i-...
| is the first one. All of them (I think there are five) are great.
|
| * Letters to a New Developer:
| https://letterstoanewdeveloper.com/the-book/ Please note I wrote
| this, but I still think it does a good job of discussing the
| "soft skills" in an easily digestible format.
|
| * Pragmatic Programmer by Dave Thomas and Andy Hunt:
| https://pragprog.com/titles/tpp20/the-pragmatic-programmer-2...
| Haven't read the revised 20th anniversary edition, but the first
| one opened my eyes to the craft of software.
|
| * High Output Management by Andy Grove:
| https://bookshop.org/p/books/high-output-management-andrew-s... a
| great way to think about throughput
|
| * The Phoenix Project by Gene Kim et. al:
| https://itrevolution.com/product/the-phoenix-project/ Fun
| novel(!) about applying lean management principles to software
| engineering.
|
| * Radical Candor (haven't read, but it's been recommended):
| https://www.radicalcandor.com/ About communication.
|
| * Good to Great by Jim Collins:
| https://en.wikipedia.org/wiki/Good_to_Great Focuses on what great
| companies bring to the table. Helps me evaluate where to work.
|
| * Mastery Autonomy and Purpose: A great video about what people
| really want in work: https://www.youtube.com/watch?v=MzXXC4MZZnY
|
| * https://www.manager-tools.com/podcasts a podcast about managing
| people. You didn't say you wanted to be a people manager, but
| knowing what managers think about will make you more effective in
| any org.
|
| * Managing Humans by Michael Lopp: https://managinghumans.com/
| The whole Rands site is work reading, but I enjoyed this book
| about how to manage teams and build software. See above.
|
| * Don't Make Me Think by Steve Krug: https://sensible.com/dont-
| make-me-think/ Easy ways to think about usability, focusing on
| webapps. Short and easy.
|
| * Badass: Making Users Awesome, by Kathy Sierra:
| http://seriouspony.com/badass-users-the-book Will help you put
| yourself in the shoes of your users and think about how to build
| software they will love. Short and easy.
|
| Hope this helps.
| bilsbie wrote:
| Anyone know if the old Joel on software essays are still around?
| Are they still relevant?
| mooreds wrote:
| I think they are (I put them in my response :) ). I still think
| about this one periodically:
| https://www.joelonsoftware.com/2000/05/12/strategy-letter-i-...
|
| I didn't see all the letters outlined in any location, so why
| not here:
|
| https://www.joelonsoftware.com/2000/05/12/strategy-letter-i-...
|
| https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...
|
| https://www.joelonsoftware.com/2000/06/03/strategy-letter-ii...
|
| https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
|
| https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
|
| https://www.joelonsoftware.com/2007/09/18/strategy-letter-vi...
|
| Hard to beat his writing style.
| bilsbie wrote:
| Thanks! Looks like his main page has all the articles plus
| classified into different groupings like top 10.
| jm1271 wrote:
| Software Estimation: Demystifying the dark art is an under-
| appreciated book in this area.
| cpitman wrote:
| Given it is pretty short, easily one of the best investments I
| have made in time.
| mooreds wrote:
| Is that this book?
| https://books.google.com/books/about/Software_Estimation.htm...
| pkoird wrote:
| So I asked this same question to ChatGPT, here's its response.
| This thing really does have the potential to be a good
| recommendation tool for books/resources.
|
| "Here are a few books that may be helpful for improving your
| skills as a software engineer:
|
| "The Pragmatic Programmer" by Andrew Hunt and David Thomas: This
| book offers practical advice on a wide range of topics, including
| how to write clean and maintainable code, how to work effectively
| with others, and how to manage your time and priorities.
|
| "Clean Code" by Robert C. Martin: This book focuses on the
| importance of writing code that is easy to read and understand,
| and provides specific guidance on how to write clean and
| maintainable code.
|
| "Peopleware" by Tom DeMarco and Timothy Lister: This book
| discusses the human side of software development, including how
| to create effective teams and work environments, and how to avoid
| common pitfalls such as overwork and burnout.
|
| "Agile Software Development" by Alistair Cockburn: This book
| provides an introduction to agile software development
| methodologies, which are designed to help teams deliver high-
| quality software quickly and efficiently.
|
| In addition to these books, there are many excellent blog posts
| and online resources on these topics. Some websites that may be
| helpful include the Pragmatic Programmer blog, the Agile Alliance
| website, and the ACM SIGSOFT Software Engineering Notes journal.
|
| Another helpful resource may be attending conferences and
| workshops on software engineering and related topics. These can
| provide opportunities to learn from experts in the field, network
| with other professionals, and stay up to date on the latest
| trends and best practices. Many conferences and workshops also
| offer certification programs, which can be a valuable way to
| demonstrate your knowledge and expertise to potential employers.
| Some well-known conferences in the software engineering field
| include the ACM SIGSOFT International Symposium on the
| Foundations of Software Engineering (FSE), the ACM SIGCHI
| Conference on Human-Computer Interaction (CHI), and the
| International Conference on Software Engineering (ICSE). "
| KunafaPizza wrote:
| This answer scares me. Wow
| marvin wrote:
| I aim to ignore this advice and spend the next year figuring
| out how to leverage LLMs to become a more productive software
| engineer. Unfortunately there's no books on it yet.
| DonsDiscountGas wrote:
| Maybe you could do the experiments and write the book.
| pkoird wrote:
| Yep, it has recommendations for every single subject!
| brysonreece wrote:
| Right? This thing is more eloquent with its words than I am
| with my own.
| kace91 wrote:
| How did you get that?
|
| Any attempt I do at recommendations or summaries of books is
| met with a cookie cutter response that it can not do
| recommendations because it can't access the internet.
| foobazgt wrote:
| OP, I've been thinking about starting a column on those kinds of
| lines - generalized engineering advice. I have 20+ years of
| experience in the industry and have held both principal engineer
| and engineering director positions at S&P 500s. Does that hold
| your interest?
|
| For everyone else, I think I've created an interesting backlog of
| topics, but I'd love any advice about additional topics that
| would interest folks, how to kickstart an initial audience, what
| platform to use, how to moderate without losing my mind, and
| anything else that'd be useful to know doing this kind of thing.
| ArcMex wrote:
| I'm interested.
|
| My main topic of interest is how much has changed over time and
| perhaps what the next 20+ years hold. Such discussions can be
| eye opening when considering what direction to take, for
| example, when adopting frameworks and methodologies.
|
| Looking forward to your content.
| mooreds wrote:
| > I'd love any advice about additional topics that would
| interest folks, how to kickstart an initial audience, what
| platform to use, how to moderate without losing my mind, and
| anything else that'd be useful to know doing this kind of
| thing.
|
| What are your goals? Just to get your stuff read, help other
| folks be better engineers, to build a consulting business, to
| build a recruiting pipeline, something else?
|
| Your goal affects any advice I'd give.
| [deleted]
| hardwaregeek wrote:
| I'm currently reading Peopleware which is simultaneously very
| insightful and very obvious. It's also a bit of a marker in time
| of how software development worked. I'd say a lot has improved
| with remote work, at least for some companies.
|
| I found The Mom Test pretty helpful for honing a product mindset.
| I've fallen into the trap of writing code simply because I find
| it less daunting than talking to users. The Mom Test is a good
| reminder on priorities.
| mooreds wrote:
| Oh man, Peopleware was so good when I read it in the 2000s. You
| indicate that time has passed it by a bit? Any particulars you
| remember?
| randomsearch wrote:
| Everyone even thinking about creating a startup should read
| "The Mom Test" first.
| rubicon33 wrote:
| Recommend this book, but honestly you don't need to read it:
|
| Deep Work: Cal Newport
|
| What you need to know from this book is that to write good
| software (both quality and quantity) you need to go deep. You
| need to fully absorb and understand the problem in your mind,
| BEFORE you begin writing code. And then, you need quiet
| undistracted time to map the thoughts in your mind, to code on
| paper.
|
| This process of turning a mental model in your mind, into a well
| designed code model, takes more focus than you think (if you want
| to do it well). Give yourself a quiet room with no visual
| distractions. Just you, and your code. Set aside a few hours.
|
| Most importantly of all - Remove the possibility in your mind,
| that a distraction could happen. I cannot emphasize this enough.
| Your mind will not go deep if, even on a subconscious level, you
| think a distraction could come. A text message, a spouse walking
| in, a co-worker asking a question, etc. These all need to be (as
| reasonably as possible) NOT possible so that your mind can go
| quiet, and you can take on the work.
| ArcMex wrote:
| I would have loved to see you talk about the part of the book
| that addresses working with others, as that seems topical to
| the OP.
|
| Overall, it is also my recommendation, in that when you develop
| a good habit of churning out quality work, it enhances your
| contributions to the team.
| bitsofawesome wrote:
| The two most useful books I have read: Code Complete by Steve
| McConnell - Really covers how to be good at the craft of writing
| programs and constructing software.
| https://www.amazon.com/Complete-Microsoft-Programming-Steve-...
|
| The Effective Engineer by Edmond Lau - Covers how to focus on
| what you work on based on the leverage it provides you.
| http://www.effectiveengineer.com/
| ChrisMarshallNY wrote:
| _> Code Complete by Steve McConnell_
|
| +1. Also, _Rapid Development_ , by McConnell[0]. I would say
| that it's even better than _Code Complete_.
|
| It would be considered "quaint," these days, but _Writing Solid
| Code_ [1], by Steve Maguire, was a seminal book in my
| education. I still use many of the techniques he mentioned.
|
| And I cannot say enough about _The Design of Everyday Things_ ,
| by Don Norman[2]. That book changed my life. I would consider
| it required reading, for anyone that develops _anything_ that
| will be used by other humans.
|
| [0] https://www.microsoftpressstore.com/store/rapid-
| development-...
|
| [1] https://writingsolidcode.com
|
| [2] https://jnd.org/the-design-of-everyday-things-revised-and-
| ex...
| chiefalchemist wrote:
| +1 for the Norman book. A bit verbose, but in the end worth
| it.
|
| Krug's "Don't Make Me Think", while more UI / UX is a solid
| compliment to "Everyday Things."
| pieterr wrote:
| Camille Fournier - The Manager's Path
|
| https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...
|
| https://www.elidedbranches.com/
| brnstz wrote:
| Worse is Better:
| https://www.dreamsongs.com/RiseOfWorseIsBetter.html
| dxs wrote:
| You can take a look at the following. Doesn't look like anyone
| else has mentioned this yet.
|
| As with everything else, check it out, adopt what looks good,
| adapt it to your needs.
|
| > Watts Humphrey: https://en.wikipedia.org/wiki/Watts_Humphrey
|
| > Personal software process:
| https://en.wikipedia.org/wiki/Personal_software_process
|
| > Team software process:
| https://en.wikipedia.org/wiki/Team_software_process
|
| > More at Libgen:
| http://libgen.rs/search.php?req=watts+humphrey&lg_topic=libg...
|
| > More at PDF Drive:
| https://www.pdfdrive.com/search?q=watts+humphrey&pagecount=&...
| kyleee wrote:
| ChatGPT's answer:
|
| There are many books and resources available on the topics you
| mentioned. Here are a few suggestions:
|
| "The Mythical Man-Month" by Frederick P. Brooks Jr. is a classic
| book on software project management. It covers topics such as the
| challenges of managing large, complex projects, and how to avoid
| common pitfalls.
|
| "The Art of Agile Development" by James Shore and Shane Warden is
| a practical guide to agile software development, which emphasizes
| collaboration, flexibility, and continuous improvement.
|
| "Getting Things Done: The Art of Stress-Free Productivity" by
| David Allen is a popular book on time management and
| productivity. It provides a framework for organizing and
| prioritizing tasks, and offers strategies for dealing with
| distractions and interruptions.
|
| "Influence: The Psychology of Persuasion" by Robert B. Cialdini
| is a book on the psychology of persuasion and how to apply it in
| business and personal relationships. It covers topics such as the
| six principles of persuasion and how to use them effectively.
|
| In addition to books, there are also many online resources and
| blogs that offer advice and guidance on project management, team
| dynamics, and related topics. Some good places to start are the
| Project Management Institute (PMI) and the Agile Alliance. You
| can also search online for blogs and articles on these topics to
| find more specific information and advice.
| OJFord wrote:
| About 1/3 of the homepage is already directly about ChatGPT,
| please let's not have every other submission's comment section
| dominated by it too...
| hxugufjfjf wrote:
| This mindset is unfortunately futile now. 90 % of what you
| see on HN, both posts and comments is eventually gonna be AI
| generated and largely indistinguishable from human made
| content in not very long time.
| lgas wrote:
| It's a good answer, who cares where it's from?
| OJFord wrote:
| Then just post it, without drawing attention to where it's
| from and making _that_ the inevitable discussion?
| TillE wrote:
| The last two books are not even close to relevant to the
| question, they're just generic business-flavored self-help.
| groby_b wrote:
| I can promise you that if you don't learn to get
| organized and if you don't learn to influence people,
| there's a ceiling to where you can go as a software
| engineer.
|
| I don't know if I had recommended these specific books,
| but they're certainly relevant.
|
| To bring this back to the main topic: For
| persuasion/negotiation, I prefer Stuart Diamond's
| "Getting More". For negotiation & communication with a
| power differential, I'd go for "Nonviolent communication"
| by Marshall/Rosenberg. (For finding an organization
| scheme, IDK. GTD is not the worst book. I know of none
| significantly better, but I also question the nature of a
| work environment where we drown in tasks. So, maybe Cal
| Newport's books instead)
| Noe2097 wrote:
| Try "Extreme Ownership".
|
| It will give you concrete examples on how to broaden your scope
| out of just your individual contribution, by learning to care for
| all the rest, and pushing you to realize that to a large extent,
| the things you see as broken you can actually fix.
|
| Even when they are not inside the codebase you are in charge of.
| Even if they aren't even on engineering side.
| merolish wrote:
| This list was posted a few months ago:
| https://news.ycombinator.com/item?id=32305997
| ayewo wrote:
| Mythical Man Month by Fred Brooks is pretty good. There is also
| the Design of Everyday Things (TDoET) by Don Norman.
|
| Structured Design from 1975 by Larry L. Constantine and Ed
| Yourdon is another excellent book that I am currently reading
| now.
| ldjkfkdsjnv wrote:
| My personal opinion is reading about coding does nothing. Its
| like reading about math without doing the exercises. You need to
| work on good codebases, and have your code reviewed by people who
| are good.
| paulryanrogers wrote:
| My guess is it varies per person. Reading still helps spark
| some ideas for me, though without exercising what I've read it
| the learning doesn't stick.
|
| Even better is learning from people better than me. Video
| tutorials can help too, especially where seeing output is
| important.
| Sakos wrote:
| > reading about coding does nothing
|
| > Its like reading about math without doing the exercises
|
| But you do learn math from reading and then you practice it to
| improve your understanding with exercises. It's not an either
| or. It's both. You should be reading about software development
| as well as actively improving your code in practice. I don't
| think you'd get even half as far if you only did one of the two
| things.
|
| This is such a bizarre point of view that I'm seeing
| increasingly. "Reading does nothing". Since when?
| hardwaregeek wrote:
| Yeah I had a boss who, when I mentioned that I was reading
| about startups and recommended the books, dismissed them
| saying that it didn't seem like one could learn from books.
| Which seemed like a weird dichotomy because nobody's saying
| you can learn how to run a startup entirely from a book?
| We're just saying you can learn some useful elements or
| perspectives from books. Which is really all that you can ask
| for from instructional material.
| nouveaux wrote:
| Obviously if you land in a perfect environment, then you won't
| need outside resources.
|
| I am self taught in how to write good code by reading books,
| watching videos, and reading recommended open source code. I
| was never in an environment with other great coders who
| reviewed my code. HN was my guide in how to learn to write
| better code.
|
| It is possible to be self taught at writing good code.
| hardwaregeek wrote:
| I don't know why this is phrased as a dichotomy. You can work
| on a good codebase with good people _and_ read books. You can
| also be in a less than ideal situation and at least read books.
| Unless these books are actively hurting you, which is pretty
| unlikely imo, it's not a bad idea to read them.
| loloquwowndueo wrote:
| I got a ton of value out of "Peopleware: Productive Projects and
| Teams". Even if you're not a manager that can directly follow the
| advice, as an engineer it will provide great clues on how to
| ensure environment and team dynamics can greatly influence
| efficiency and chances of success.
|
| Of course my all time favorite is The Mythical Man-Month. But
| that's already mentioned elsewhere in this thread.
|
| I haven't read "Drive: The Surprising Truth About What Motivates
| Us" but some of the concepts it talks about are also of interest
| (on how to ensure workers are motivated and I'm not talking about
| "the beatings will continue until morale improves" :) )
| leetrout wrote:
| A Philosophy of Software Design
|
| https://web.stanford.edu/~ouster/cgi-bin/book.php
|
| Righting Software
|
| https://rightingsoftware.org/
| summertime42 wrote:
| I have all of these on my shelf. Fantastic reads.
|
| * Extreme Programming Explained by Kent Beck
|
| * Clean Code and The Clean Coder by Robert C. Martin
|
| * Soft Skills by John Sonmez (1st edition)
|
| * Pragmatic Programmer by Andrew Hunt and David Thomas
|
| * Working Effectively with Legacy Code by Michael Feathers
|
| * The Mythical Man-Month by Frederick Brooks
|
| (Selfish plug) Additionally, I wrote my own book concerning the
| entire industry, from just starting out to becoming a self
| employed consultant when you get sick of fulltime work - all soft
| skills from my decade or so of the industry, as well -
| https://www.amazon.com/dp/B0B43V1JJW
| charles_f wrote:
| To the point of the question I would much more recommend "Clean
| Coder" by uncle bob, which mostly deals about the professional
| ethics of software development
| cokeandpepsi wrote:
| Robert C. Martin has ruined so many mid organizations it's kind
| of funny
| pushedx wrote:
| Having never read Clean Code, why do you say that?
| Chris_Newton wrote:
| Someone wrote a lengthy and detailed critique of _Clean
| Code_ a little while back:
|
| https://qntm.org/clean
|
| As someone who also recommends against improving developers
| reading _Clean Code_ , I think the arguments in that piece
| are generally on point.
| teddyh wrote:
| If you want your criticism to be taken seriously, please be
| specific.
|
| There is apparently a large group of people who hate
| everything he does and also, seemingly, him personally.
| Everywhere he (or any of his books) is mentioned, the haters
| come out, with their vague "it's all bad" and the old
| standard "I don't know where to begin". Serious criticism can
| be found (if you look for it), and he himself welcomes it,
| but the constant vague hate is scary to see.
| tester756 wrote:
| Years wasted on having to convincing people that "comments
| are viable" because they misunderstood Clean Code
| teddyh wrote:
| Sounds like people being stupid? I mean, he never says
| that comments are not viable: like you say, they
| misunderstand the book.
| mikehollinger wrote:
| "The Effective Manager" by the people behind Manager Tools (a
| great podcast) is a really, really good view of this.
|
| Re: Communication, this book starts there and builds upon that
| foundation. It's targeted at line managers, but anyone in a
| leadership position can and will benefit. For example, I don't do
| one-on-one's with my team. I do "Project Management 1:1's" or
| "Weekly project status updates." I don't always give feedback the
| way they prescribe (because the team doesn't formally report to
| me). I do, however, go out of my way to say "Just to let you
| know, when you do X, Y happens." And from the book, learned that
| there's a 10:1 ratio of positive to negative feedback to strive
| for.
|
| Side note: Manager Tools has a great podcast series that is
| arranged into a "map of the universe" [1] which shows a huge list
| of topics, and how to discuss everything from good or bad
| performance, dealing with various types of conflict, to even how
| to structure emails or how to address a personal scent issue
| (which I've actually used).
|
| [1] https://www.manager-tools.com/map-of-the-universe
| plugin-baby wrote:
| > how to structure emails or how to address a personal scent
| issue (which I've actually used)
|
| How did that play out?
| mikehollinger wrote:
| Honestly pretty well.
|
| One of our colleagues took aggressive advantage of the ping
| pong tables at the office (in the before times) every
| afternoon after lunch. I'd noticed as had some others. I had
| a short talk with that person about the fact that in a shared
| office environment he was essentially showing up post-workout
| for the balance of the afternoon. I actually don't recall
| what changed - but we stopped noticing the issue. I think
| they just started playing toward the end of the day then just
| went home after.
| chiefalchemist wrote:
| "You're Not Listening" by Kate Murphy.
|
| It's not at all software related but it will make you a better
| teammate, partner (i.e., client relationship), manager and/or
| leader.
|
| Technology is the easy part. People, that's the difference
| between average and above.
| tonto wrote:
| "Software engineering at Google" (O'Reilley) has a lot of "team
| focused" advice also, it's overall pretty non-technical but
| generally a good read. Free to read online too
| https://abseil.io/resources/swe-book
| TruffleLabs wrote:
| The Mythical Man-Month: Essays on Software Engineering, Frederick
| P. Brooks * still relevant re: people are the key to getting
| things done; understand how people work together.
|
| https://www.abebooks.com/products/isbn/9780201006506
| avg_dev wrote:
| I really liked his other book The Design of Design as well.
| They go well together.
| ilaksh wrote:
| My suggestion is that besides reading books, you could try to
| build a startup. It could just be consulting on your own (or with
| ChatGPT or Fiverr/freelancing sites as your team). Then you will
| gain direct experience in a lot of those things.
|
| Also here are a few ideas for managing scope, deliverables,
| expectations, time management. Structure things financially so
| that they are tied to relatively short iterations that require
| direct interaction with working software and between the
| engineers and the users and management at regular intervals. The
| communication with users AND management, payment, and deployment
| of working software at regular intervals should be strictly
| enforced. The project should not continue into the next iteration
| until all of those requirements are met for the current one.
| mooreds wrote:
| Maybe I'm splitting hairs, but a startup != a consulting
| company to me. You'll learn valuable skills doing either, but
| they aren't the same.
|
| Consulting is way way easier.
|
| Signed, a former consultant and startup CTO.
| ArcMex wrote:
| I agree.
|
| Soliciting for business and sustaining good relationships, in
| particular, will enrich one's experience overall.
|
| I've learned many lessons - everything from improving my craft
| to knowing when to drop a problematic client or project.
| jshen wrote:
| Become a better story teller and persuader, and learn how to make
| better decisions and manage risk. A few books that helped me in
| no particular order ...
|
| The Science of Storytelling - Will Storr
|
| Influence - Robert Cialdini
|
| Thinking Fast and Slow - Daniel Kahneman
|
| Antifragile - Nassim Taleb
|
| How Innovation Works - Natt Ridley
|
| The One Thing You Need to Know - Marcus Buckingham
|
| Team of Teams - General Stanley McChrystal
| ArcMex wrote:
| I'm always looking to improve my set of skills, so thank you for
| the thread and thank you for the responses- I have managed to
| pick up some recommendations.
|
| My personal recommendation would be Deep Work by Cal Newport as
| it is my most recent read, having completed it just the day
| before yesterday.
|
| I applied what I learned and discovered that I was able to meet
| deadlines much easier than before. I'm also in the process of
| applying deep focus techniques to my work weeks to ensure I have
| a tangible build or product every Friday. Could be a document, a
| repo, a feature, etc. So far so good. This past week I delivered
| a Design Spec document in record time.
|
| Thanks again and take care.
| vasco wrote:
| I know you asked for books or blog posts, but I believe the best
| way is to read lots of code from the tools you use. Look into how
| your favorite libraries do things, for a start.
| mooreds wrote:
| How does that help with what the OP asked for? "What I'm
| seeking is reading material regarding how to manage project
| scope, be better team member, converting asks to deliverables,
| managing expectations from management, enabling team members by
| opening communication channels across teams, time management,
| etc."
|
| I think reading code is great for learning more about code, but
| don't see how it helps with the other items on that list.
| rahimnathwani wrote:
| Staff Engineer: Leadership beyond the management track by Will
| Larson (https://staffeng.com/book)
|
| Peopleware
| kiernanmcgowan wrote:
| Also check out his guides which are freely available. We've
| been using these as a way to answer the question "what does a
| staff eng do?" at clearbit.
|
| https://staffeng.com/guides
___________________________________________________________________
(page generated 2022-12-04 23:00 UTC)