Debugging the development process

What Hacker News says

1. DanielBMarkhamFeb 2022
   I'll take a shot, assuming that you are asking how to manage a technology team, not how to understand technology at a wider scale. You need both tech leadership and end-to-end/shallow-deep abilities. But the tech side is a different question entirely. Looks like some other folks have provided answers so I won't go there. (The tech side is a lot to go into in a thread, and would include some kind of conversation figuring out where you are technically. "I'm a SWE" doesn't begin to cover it.)

   Without any thought at all:

   - One Minute Manager

   - Debugging the development process

   - The Culture Code

   - The Five Dysfunctions of a Team

   - Difficult Conversations

   Take some negotiation and interviewing hands-on courses.

   Show morethread
2. tankerdudeApr 2018
   Bezos is a really smart guy but here, I beg to differ. I interviewed for a management role over at Amazon. I asked them what they thought of work life balance and how many hours are we talking about a week. 60 or so was the minimum, and that doesn't include lunches. 12+ hour days didn't seem like something you can sustain no matter how much energy you have.

   Sooner or later, you will get physically and mentally exhausted at work, even though you have lots of fun doing so before you get wiped out.

   I also informed them that if your engineers are working 70+ hours a week basically every week, then you don't have an engineering problem but a management problem. It's no longer a work-life balance, but purely a work-work balance, and that it was up to management to ensure that they don't burn their engineers out.

   I didn't get to the next round (thankfully). I didn't "fit their culture". So I thanked them and moved on. Better for them, better for me.

   I personally want people who are effective, and can put in a solid day of work. I still pull wisdom from, "Debugging the Development Process" back from 1994. I think it still holds true today for many aspects of software engineering. Or am I really an outdated curmudgeon?

   Show morethread
3. jwatteDec 2017
   In "debugging the development process," the author recommends the method of "make a quick estimate, then give a range between that and 5x that. Suggest that the estimate can be made narrower only with significant additional scheduled work."

   I like it, because it's true, it works, and it deals with the inherent uncertainty of software development by letting those who ask decide how much they want to pay for how much certainty.

   Show morethread
4. MalicOct 2015
   DeMarco and Lister's "Peopleware: Productive Projects and Teams" was published way back in 1987 with 2 new editions over the years.

   And even the first edition untouched is still completely relevant.

   While its focus is "getting teams to work well together and develop good software", I think it has excellent viewpoints and advice for any workplace where people use their brains for a living, regardless of what the company does.

   I'd also like to add "Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams" by Steve Maguire.

   Show morethread
5. RogerLNov 2013
   This has nothing to do with tech, IMO. Wander over to Wall Street, go into some white collar office with a bunch of people doing data entry, go to some fulfillment center warehouse, and then go to a construction site and you'll see the same behavior.

   Managing people is not trivial. So, to bring tech into it, it really boggles my mind when I see these awful styles. I mean, we spend years developing our skills, and break our arms patting ourselves on our back on how skilled we are. Then, for whatever reason, we end up on the people side and suddenly making it up as you go is fine. We have books on managing people - they are not a panacea, but I'm shocked at how few people in these positions have heard of them, let alone read them.

   For example, the Microsoft Press books form the 90s are great. Debugging the Development Process, Software Project Survival Guide, Writing Solid Code, Rapid Development, and then books like The Mythical Man-Month, and Peopleware. Just a passing familiarity is all I ask. But no. Favored people and 'can't be hit by a bus' people get away with anything, great people with a few rough edges get fired at whim, no guiding principles on what it takes to execute a project (get shit done doesn't count, sorry), no concept of personal development. Ugh.

   Show morethread
6. RogerLSep 2013
   Why would you bet that?

   We have a broad understanding of how to structure and write software. These ideas have been collected together in books. I refer to books like Code Complete, Debugging the Development Process, Clean Code, Refactoring, Programming Pearls, Beautiful Code, and so on. Then there are the language specific books. I don't believe you can craft well written C++ without reading Scott Meyers' books (or having absorbed the same knowledge from others), for example. Even the much maligned Design Patterns, which has been turned into the truly dreadful design by pattern, helps us to think about how to structure code.

   I can't type it all in a post. But we are talking about modularity and extensibility. Decoupled code, so you can make changes here that don't break something over there, and so you can easily move code from one project to another. Well commented code - where 'well' means the author takes the use of the code into account - some deeply internal function named ComputeAverageSalary probably doesn't need much in the way of extra comments, anda top level api call to a framework being used by thousands needs a lot of documentation. Well structured code. The if statements make sense. They are not deeply nested. logic is not duplicated, or contradicted when it is nested, because that always leaves you scratching your head as to the purpose of the author(s), and clueless as to how to add code.

   So, back to the question, why would you bet that? I've opened plenty of 15 year old code that is good to beautiful. This is not an arbitrary judgement of "oh, OO good/bad", nor an reactionary "it wasn't written by me, so it must be bad".

   I do consider myself a pretty clean programmer, but I learned it by observing the code of others, reading a lot of books, and relentlessly applying a critical eye on everything I write and others write. All borne not on some arbitrary judgement, but from recognition of how quickly/slowly I can grok a piece of code, how easy it is to find and fix bugs, how easy to add features, and so on. In some code bases that is all fairly straightforward, and in others it is impossible - any fix or change has so many side effects that you need to add 50 if statements strewn about 50 files, in code already filled with if statements, and your if statement break about 15 undocumented assumptions about the behavior of the tightly coupled code.... that, my friends, is shit.

   Show morethread