1. 122
  1.  

  2. 79

    90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.

    You have no idea how much they are shielding you from being pestered on project status, and constantly reorganizing the project plan to fit the mental model of some executive new to the project.

    1. 52

      Good project managers do that. Bad project managers pass it along and sometimes even amplify it.

      1. 29

        This is 100% correct. You really don’t realise how much bullshit managers deal with until you have to fill that role yourself.

        1. 5

          Totally agree. Being a manager is quite stressful and not everyone knows that

        2. 19

          Actually, I do, and I wholeheartedly agree with the poster.

          How do I know? Simple: I’ve had projects with and without project managers, in similar and sometimes even the same companies, so have fairly direct empirical evidence of the truth of the statement. I’ve also been in management positions myself (not “project management”).

          At one FAANG, the performance team and a product team had achieved a good working rapport and decided to do a longer-term collaboration to improve a crucial platform application. Then the project managers, who had felt left out, got involved and the whole thing blew up in acrimony.

          Another project manager, 1 week before ship date (that we hit): “I’ve changed all tasks in the tracker to P1, so you will actually do them”. Gosh.

          At a third company, we had an ongoing problem that had been around and festering for years, long before my manager and I had started, and that seemed trivial to solve but for some reason proved completely intractable. Then we got a new head of department, my manager scheduled a meeting with her, we all sat in and … solved it. Trivially.

          Baffled, I asked my manager how he had done that, just solved the intractable problem. He gave a little smirk and replied, “Oh, it’s easy, just don’t invite -name- to your meetings.” Who was -name-? Head of product management.

          At that same company, our project was too small and unimportant to rate a product manager. After it turned out, for some bizarre und totally unrelated reason, that we managed to be hugely successful where the projects in our surroundings were all struggling at best, a project manager decided to take pity on us and offer us her services. We declined.

          In that team and at other successful ones, the project team had a direct rapport with the customer and/or was defining the product largely autonomously. Which works amazingly well.

          Note also that 90%-93% is not 100%. At one startup where I’d been asked to come in and rescue their Mac project, it quickly became clear that we were completely fu**ed: 2-3 engineers, often multiple daily meetings with more than 10 people in the room. Surprisingly progress didn’t improve despite them calling more progress meetings. A mystery.

          They had actually hired a program manager in addition to the project managers, which is a whole other level of bizarre. But she was very good and quickly understood the problem. We made a pact that she would distract the apparatus while the team and I got a chance to finish the project. Which we did, first (and I think only) time in the history of that company that a product shipped on time.

          After we finished they fired her and had a stern talking to me that we had been given a pass so far but would have to follow their standard best practices from now on.

          1. 4

            After we finished they fired her and had a stern talking to me that we had been given a pass so far but would have to follow their standard best practices from now on.

            That is /awesomely/ awful. I love it.

          2. 12

            Agreed. Much like janitors, good project managers are noticed when they’re bad at their jobs.

            1. 4

              Which is the case of the 90%+ the OP talks about. Having worked with hundreds of them, I would say it’s more like 95%+.

              I take it some people in here are managers and don’t like this to be said. Get over it, there’s plenty of talk about bad engineering on this website, mostly done by engineers.

            2. 7

              It’s quite likely that the author’s view was shaped by project managers who do nothing but pester you on project status and constantly reorganise the project plan so as to demonstrate how important they are to the people upstairs. The exact percentage is up for debate I guess. In my experience the number is probably around 90%, too, but it’s… a complicated matter.

              1. 2

                You must have been blessed with good project managers…

                1. 1

                  At least where I work the project managers are mostly for reporting upwards, they run the monthly stakeholder meetings and such.

                  1. 1

                    Consider that you may have been lucky.

                  2. 26

                    After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better.

                    yep

                    1. 2

                      Maybe Amazon’s interview is broken. This data-structure bullshit doesn’t help at all if the applicant doesn’t know shit about real work, system designs, soft skills, security, team work, etc

                      1. 4

                        As much as I dislike FAANG interviews, every attempt I’ve seen to fix them is also fraught with problems

                        1. 6

                          I’d love to work for one of those big FAANG but I don’t know from the top of my head how to do a BFS on a tree. So fuck it, my 20 years of development is garbage for them.

                          1. 4

                            There are many books and courses to prep candidates for FAANG interviews. For senior engineers might be daunting but to join a FAANG some drills are to be expected.

                            Whatever company will have a big pool of candidates will end up in similar situation: assess things that are largely irrelevant to the day-to-day job.

                            The real drama is that very smart people who could use their brain-power to improve society at large, deal with low utility projects for years.

                            1. 4

                              You’re doing yourself a disservice by having this mindset

                              1. 1

                                Why?

                                1. 1

                                  Because you don’t get to work at FAANG

                              2. 3

                                I seriously believe that if you are a good programmer, went to uni or similar and spend two weekends with “cracking the coding interview”, do 1 or 2 mock interviews to train the communication style, you have a good chance. If you aren’t anxious or have other such problems during the interview.

                                Without preparation most would be lost.

                                You can, of course, still think this is fucked but it’s not unpassable for good programmers without anxiety problems, reasonably good communication skills and time to prepare.

                                If you are interested, I can do a mock interview with you.

                                1. 15

                                  I don’t think the problem for most people is the details of playing the game. The game is learnable, and if one has gotten anywhere in this field its because one can learn things. The problem people have is they question why the game, which everyone knows has no bearing on the ability to do the job at hand, needs to be played at all?

                                  If we put our cynicism hat on (mine is pretty worn-out by now), we can answer that question by saying that what the game is about is testing people’s willingness to jump through arbitrary hoops. In that sense, it may actually accurately test their ability to function within the organization at hand, and thus may in fact be very good at its job of filtering out candidates who would not work out.

                                  1. 5

                                    but it’s not unpassable for good programmers without anxiety problems, reasonably good communication skills and time to prepare.

                                    It’s not, but good programmers with 20 years of experience can always get a job someplace where they don’t have to jump through these silly hoops.

                                    It works surprisingly well for both parties. It’s not like recruitment heads in Big Corp don’t already know this puts off experienced programmers, everyone’s been aware of that for a long time now. They just don’t want that many experienced programmers. If you’re recruiting for senior and lead positions, it’s much more efficient to go through recommendations (or promote from within) in which case the interview is… somewhat more relaxed, so to speak. The interviews are designed for something else.

                                    (Edit: I’m with @gthm on what they’re designed for . The main aim is to select young graduates and mid-career developers who will put up with arbitrary requirements and don’t mind spending some of their free time on it every once in a while.)

                                    1. 2

                                      Having been through the Google interview gauntlet a few years ago, there’s quite a bit more than just whiteboarding algorithms.

                                      I was completely unprepared for the ‘scale this data query service’ chunk, which I didn’t even know was going to be part of the interview (which is a failure of the Google recruiter frankly) but I now know is pretty standard amongst FAANG company interviews for SRE type roles. Didn’t help that the interviewer was a jerk who refused to answer any of my questions, but that’s hardly unusual!

                                      1. 2

                                        That part is also covered in “Cracking the Coding Interview”

                                        Not to invalidate your experience but the vast majority of my interviewing experience was pleasant. Maybe you have had bad luck or me good luck or your standards are different.

                                        1. 3

                                          1 grumpy jerk who clearly didn’t want to be there, 2 decent guys & a third who was OK but stone walled me when I asked questions about the problem he posed. Which was a little weird, but there it is.

                                          (CtCI has 5 pages on system design & about 100 pages on data structures, algorithms & all the rest. When a quarter of the interview is system design, that’s not going to help you much. There are some good online resources around these days though.)

                            2. 18

                              People who stress over code style, linting rules, or other minutia are insane weirdos

                              Having an automatic clang-format filter on git check-in solves so many of these pointless arguments.

                              1. 20

                                Oh, the insane weirdos will find things to bicker about even if you pass every linter rule there is.

                                I wish I were kidding but you’ll find, for example, that if you do something like this:

                                buffer.append("\r\n");
                                buffer_len += 2;
                                

                                in a single place, as part of a completely non-essential function in a 2,000-line program, they’ll complain about the magic number on the second line. Rewrite it like this:

                                buffer.append("\r\n");
                                buffer_len += len("\r\n");
                                

                                yep, you’ve got it, they’ll complain about the magic string on both lines, plus what happens if someone changes the first one and forgets to update the second one (“yes I know the spec says lines are always terminated with \r\n but it’s not good programming practice!”)

                                No problem, you say – ironically, they’re kindda right this time, so okay:

                                buffer.append(CR_LF);
                                buffer_len += len(CR_LF);
                                

                                …but the meaning of CR_LF is very opaque, it doesn’t emphasize that this is meant as a line terminator and it may not be obvious to people who come from a Unix background, rather than Windows (oh yeah, totally, I always wondered what those weird ^M signs were in my files, yeah, it’s not obvious at all). Perhaps we should call it CR_LF_TERMINATE_LINE instead?

                                Sure,

                                buffer.append(CR_LF_TERMINATE_LINE);
                                buffer._len += len(CR_LF_TERMINATE_LINE);
                                

                                Okay, you say to yourself, clearly this is the end of the line? Nope, they’ll get back to you with something like:

                                “I think it’s okay in terms of variable names but the code as it is right now is inelegant to the point where it’s unmaintainable. It’s bad programming practice to repeat yourself (links to DRY entry on Wikipedia) – you should refactor this into a single, general function that appends a user-defined sequence to the original buffer and modifies its length accordingly.”

                                When you do that, the problem, of course, will be that the function is too general now, and you’ll really want is to add a separate, buffer_terminate_line function that calls the more general “append” function with "\r\n". Of course, you’ll now have two functions, both called from just one place: one is called by the other function, the other one is called in your code above. You got a longer, probably buggier program, but it’s so much more readable now. Assuming you named the functions correctly, that is ;-).

                                The example above is fictional for obvious reasons but I ran into it regularly throughout my career.

                                It’s a little better now that I’m a contractor – I no longer fuss about these things and will happily bill companies that don’t keep their “well ackshually” developers in check, unless they want something that’s literally wrong.

                                Edit: some of the comments around here are… like, so blissful, like y’all think these are just things that you read about on The Daily WTF but surely nobody encounters this all the time, right? You have no idea how lucky you are and I have no nice words to say to you, your happiness fills me with dread and the fact that there are programmers who don’t experience these things on a weekly basis is so foreign to me I just hate you all right now and I’m going to go to bed and hate you all while I’m waiting to fall sleep! Did I say how much I hate you, lobste.rs? Ugh!

                                Okay, no, seriously, these things are just so common that, with every year that passes, I find myself spending more and more time wondering why I still put up with it instead of, I dunno, anything?

                                1. 4
                                  buffer.append("\r\n");
                                  buffer_len += 2;
                                  

                                  Dumb question but, ah, is there some reason why buffer_len isn’t a field on buffer which is updated for you by the .append() call? ;)

                                  weirdos will find things to bicker about even if you pass every linter rule there is

                                  The inverse of this is finding weird people who go to elaborate lengths to defeat a linter a rule that is pointing out a genuine bug in software, rather than just fixing it.

                                  (This is not an accusation towards you, just that sentence reminded me of it.)

                                  1. 7

                                    Dumb question but, ah, is there some reason why buffer_len isn’t a field on buffer which is updated for you by the .append() call? ;)

                                    The fictional code example above is written in a fictional language that doesn’t allow integer fields for objects called “buffer” :-P

                                    The inverse of this is finding weird people who go to elaborate lengths to defeat a linter a rule that is pointing out a genuine bug in software, rather than just fixing it.

                                    Oooh, I have a collection of stories about this one, too :(. Way back when I was working for $megacorp, I was more or less the chief intern herder in the worst internship program you’ve ever seen. They’d hire a bunch of interns over the summer and the only plan about what to have them do was “something easy because we don’t have anyone to supervise them”. I was in one of the few teams that wasn’t ran by morons and I had some idle cycles to spare once in a while, so I’d try to help the poor souls who ended up there over the summer.

                                    One of the things they regularly ended up doing was run Coverity scans, fix the trivial bugs and report the more complex ones (super easy to quantify, right?). This would roughly go as follows:

                                    1. Ian Intern would report a bug to Grumpy Senior

                                    2. Grumpy Senior would close it without even looking at it because he had no idea who Ian Intern was, probably an intern

                                    3. I’d reopen the bug, ask them to at least confirm it before closing it.

                                    4. Grumpy Senior would close the bug immediately saying there’s nothing to confirm, it’s just a linter warning

                                    5. Ian Intern would reopen the bug with a crash dump

                                    6. Grumpy Senior would close the bug as unreproducible, Ian Intern probably did something wrong

                                    7. I’d reopen the bug because it’s a fuckin’ crash and we can’t tell our users they’re holding it wrong (this is usually where I started bringing out the tiny guns, i.e. Cc-ing managers in bug reports).

                                    8. Grumpy Senior would reluctantly look at it but it’s definitely not that, that’s just a linter warning.

                                    Now comes the beautiful part:

                                    1. Three days later, Grumpy Senior would push a bullshit fix and close the bug.

                                    2. That same day, they’d push the actual fix, with a commit message saying “Misc. style and Coverity warnings fixes”

                                    And so on – multiplied by about 40 Grumpy Seniors all over the organisation, and about six months’ worth of bad code because Coverity fixes took a lot of work so they only ran the scan once every six months :-D.

                                    1. 1

                                      The fictional code example above is…

                                      Heh. ♥️

                                      the worst internship program

                                      Oh the poor little darlings. The way the org behaved to them sounds toxic. Good on you for trying to improve it. (But alas maybe Sisyphean.)

                                      1. 2

                                        Sisyphus the game (for the Atari 2600 no less!).

                                2. 7

                                  found the weirdo! (I’m only poking fun at you)

                                  I have 100% grown to appreciate “deciding once” with automatic formatters, and resisting urges to “re-decide” as much as possible. I have ALSO realized that it can be a HUGE pain to “decide once” after you’ve already scaled to many teams + lots of code. You want to do that up front, early-on, and stick with it.

                                  1. 4

                                    :)

                                    The big advantage of having settled on a particular clang-format is that it’s not someone else’s choices that annoy, but just the arbitrary decisions of the formatter & that seems to defang the drive to nit-pick over formatting choices.

                                    I agree that it’s a huge pain to enforce a format late into a project though.

                                    1. 3

                                      My biggest gripe with many automatic formatting tools is that they pointlessly frob with line endings: clang-format will enthusiastically add or remove them by default, leading to code that I can describe as nothing short of butt-ugly by any standard. Luckily you can disable this with ColumnLimit: 0, but it’s a horrible default that too many projects use IMO. Splitting a 81-column sting over two lines is silly, and forcibly put all the arguments for XCreateWindow() on 1 or 2 lines “just because there is space” is even worse.

                                      1. 2

                                        Personally, I find working with a column limit set to around 120 nice and comfy, so I set clang-format to that & if it occasionally does something a bit odd I decide not to care about it. I save more time by never having to hand format code than I do obsessing over the odd corner case where it doesn’t make the “perfect” aesthetic choice.

                                        1. 1

                                          yep, or messing with vertically aligned code

                                        2. 2

                                          It’s not even that, I think. Not that the automation makes it so you’re not mad about the choices, but rather that you’re not forced for manually reformat a fuckload of code to please some arbitrary whinging program as the final step of every change.

                                          1. 6

                                            I often just write stuff like if x==y{return 42} now and just let gofmt deal with all of that. A small but measurable productivity boost.

                                            1. 1

                                              Exactly. Code formatters let you get on with with the actual job of writing code.

                                              I setup emacs to invoke the formatter on every enter, or with a key-binding when I want to invoke it directly. Why waste time inserting spaces / carriage returns when the formatter does a perfectly good job?

                                      2. 1

                                        Tried that in the last place I worked and people just started complaining about the formatter configuration ahaha

                                        1. 1

                                          That probably depends on the team. We have a clang-format style that isn’t my preferred style but it’s consistent and I’d much rather use a consistent style that is not quite my ideal than argue about style. Because everything is consistently formatted, if I cared enough, I could apply a different style, modify the code, and then format it back. I actually supervised a student building a tool designed for exactly that workflow (which he presented at EuroLLVM some years back; CELS: Code Editing in Local Style). I wish GitHub would integrate something like that into their code view. Don’t like the style of the project? Render it in a different style in code reviews and when you browse their code.

                                          1. 1

                                            I’m kind of okay with that in theory as long as the result is (possibly rejected) patches to the repo containing the formatter config.

                                            It might be helpful if the formatter config looks scary so people are hesitant to frob it unnecessarily.

                                        2. 9

                                          Almost everything sounds pretty spot on and I’m about 13 years in. I only took pause with:

                                          Designing scalable systems when you don’t need to makes you a bad engineer.

                                          Like most things, it depends. It depends on the definition of scalable (are we talking a few instances? Or like Google level?), as well as the definition of “when you don’t need to.” (Are we talking, right now? Or ever?).

                                          Especially since just a few lines prior there is:

                                          Software architecture probably matters more than anything else.

                                          Which to me implies stopping to think about the future of the software. Sometimes you should build in scalability and sometimes not. Anecdotally, we’ve been nearly bitten by building a service that at first had no need for scalability, but we decided to put it in because of the potential in the future. Turned out to be a great bet, as soon thereafter some new doors opened we needed that ability pronto. Had we gone with the original design we’d have missed some great opportunities.


                                          This one I agree with, but with a strong caveat

                                          Talking directly to the customer always reveals more about the problem, in less time, and with higher accuracy

                                          I very much agree, but also I very strongly believe it depends on who is talking to them. We’ve been bitten by junior team members talking directly to the customer and misunderstanding, confusing the customer or the team, or otherwise hurting the relationship due to not having the skillset (yet) to effectively go solo.

                                          Great post!

                                          1. 4

                                            Like most things, it depends. It depends on the definition of scalable (are we talking a few instances? Or like Google level?), as well as the definition of “when you don’t need to.” (Are we talking, right now? Or ever?).

                                            I’m 99% sure the author means you shouldn’t cargo-cult Google scale designs for an application running on few orders of magnitude less than 10k machines.

                                          2. 7

                                            Software architecture probably matters more than anything else.

                                            I very much agree. But how do you get good software architecture?

                                            For me the biggest topic I had changed my mind on after 6 years in the industry was: you don’t make an architecture up-front. Instead you remake it every time you add new bits of code.

                                            1. 3

                                              you don’t make an architecture up-front

                                              Absolutely. Except for the cases where you need to do exactly that.

                                              1. 1

                                                Sorry for reviving an old thread. I believe you are correct, I can sort-of imagine some of those cases. But I would also be very interested to know what examples you were thinking about.

                                            2. 5

                                              YAGNI, SOLID, DRY. In that order.

                                              As long as they all come with the caveat stated earlier in the post, namely not being a goal in and of themselves.

                                              As for the rest, it seems accurate to me.

                                              1. 8

                                                At 10 years in, I find myself agreeing with everything. It’s sufficiently rare an occasion to warrant this shamelessly me-too-ing comment.

                                                1. 4

                                                  Much as I agree with some of these things, this article is a list of hasty generalizations (esp. the one about PMs) argued from authority (“6 years experience”) without so much as an anecdote to support it.

                                                  Also, notice how they never drop an opinion without picking up at least one new one along the way? How about shedding some opinions altogether? Now there’s a liberating experience.

                                                  1. 2

                                                    argued from authority (“6 years experience”)

                                                    And in a world where we can expect a 40-year career before we can retire, that’s not much authority.

                                                  2. 4

                                                    The two with which I identify are:

                                                    Pencil and paper are the best programming tools and vastly under used

                                                    An IDE is for when you are dead-certain about what to do. Design reviews are as-important as code-reviews, and design reviews are best conducted with pencil and paper.

                                                    Typed languages are better when you’re working on a team of people with various experience levels

                                                    In the vernacular, types are a common language that improves communication

                                                    The one I slightly disagree with is:

                                                    People who stress over code style, linting rules, or other minutia are insane weirdos

                                                    Those beautifiers make it easier to do diffs; if you consistently use specific beautifiers, code reviews are easier.

                                                    1. 1

                                                      My interpretation of the formatting/linting was more about those who nitpick over things like 2 spaces, 4 spaces, or tabs. For example the code styling story is vastly different in say JS vs Elm. There are many beautifiers and linters in JS and the style always slightly changes when you move between teams or companies. I’ve even been on teams in the past 2 years that don’t use any because they don’t like them. On the opposite end you get a language like Elm where there’s 1 community formatter that doesn’t even have a config. This means that 99% of all Elm code is formatted identically.

                                                      1. 3

                                                        The Elm solution to this problem is just so much better. Just get something decent looking and consistent and shut down all the arguing.

                                                        Even if you’re someone who thinks formatting and consistency don’t matter, there will always be plenty of people to whom it does, and the only way to avoid wasted time and arguments is an auto-formatter.

                                                        1. 2

                                                          Copy that. We just try to ‘formalize’ a specific beautifier (for specific code sets) and its values and say: that’s it! Do what you want but bring it formatted to team meetings (a form of “dress code”). Diffs are where arguments start, and common beautifiers make diff analyses easier IOE.

                                                        2. 1

                                                          Those beautifiers make it easier to do diffs; if you consistently use specific beautifiers, code reviews are easier.

                                                          This is a problem with diffs though, not with code or its formatting.

                                                        3. 4

                                                          90% – maybe 93% – of project managers

                                                          I mean, that’s just Sturgeon’s Law in action, right?

                                                          I’ve worked with some stellar project managers. Specialists who cut through crappy process, poor communication, lack of prioritisation, and management upheaval to let their teams focus on getting the right thing built the proper way.

                                                          In fact, when shit is on fire, that’s when I’ve been most glad to work with a good PM. It’s just that they’re hard to find. As hard to find as good engineering managers, FWIW.

                                                          1. 4

                                                            IMO project managers are nearly always a net drain on software projects, but product managers are worth almost as much as dedicated professional testers.

                                                            1. 3

                                                              Typed languages are better when you’re working on a team of people with various experience levels

                                                              Funnily enough, the opposite is true for me. I used to be strongly in favor of typed languages, but now I simply don’t care that much. I’d say that I have less trouble navigating the project I’m currently working on (Ruby on Rails) than I had navigating previous projects written in C# and/or Java. In the end, I guess it all depends on many other factors, not just the language itself.

                                                              1. 8

                                                                Having recently (past year) learned Rails as well as Haskell I’ve found that the style of types and amount of enforced structure is a significant factor. The type systems of Haskell, Elm, etc help me a lot more than those of C# or Java. Lack of types in Rails isn’t as much of an issue because everyone writes roughly the same way. So without an expressive type system like Elm then I’d argue you need a very rigid structure like Rails.

                                                                1. 2

                                                                  My view on typed languages has both changed a lot and stayed exactly the same. I’ve always thought that most of the interesting properties that I care about and don’t want people to get wrong are not ones that type systems typically express. I’ve more recently learned about some type systems that can express those properties in a useable way, so now I’m massively in favour of strong type systems, just not the ones that most languages have.

                                                                  1. 1

                                                                    For me it kind of depends on how much turnover your team has and how much of your time is dedicated to teaching a code base or an entire language, for that matter. Sometimes newbies are competent in a codebase relatively fast, others can make dangerous mistakes without the “training wheels” typed languages tend to provide.

                                                                    1. 4

                                                                      I find no interesting codebase is small enough for all that bollocks to stay in my head, why on earth should it when we can make the computers remember it all for us?

                                                                      1. 1

                                                                        I’m not talking about memorizing a code base. I’m talking about teaching new teammates about an enterprise code base. I think knowing at least a portion of how things work is necessary before making a change. Sometimes new teammates don’t even know the language that a code base was written in, so you need to teach them about the language itself.

                                                                        1. 2

                                                                          Yikes, I’ve never been there thankfully.

                                                                  2. 2

                                                                    It would have been nice to elaborate on some points. For example, I’d like to know why

                                                                    Java isn’t that terrible of a language.

                                                                    is the case. Or how

                                                                    Trading purity in exchange for practicality is usually a good call

                                                                    was picked up.

                                                                    1. 8

                                                                      Java isn’t that terrible of a language.

                                                                      Maybe it’s because it simply gets the job done.

                                                                      Trading purity in exchange for practicality is usually a good call

                                                                      This seems to be an idealism vs practicality question. Would you want to go greater lengths only because you believe something is true? I understand this as if the OP tells us that the work environment isn’t a place for such questions. You should pick whatever gets the job done. I’ve also heard this in a different form: “if you want to build a business, choose a boring technology”. Well, unless I don’t really understand what OP had in mind.

                                                                      But yeah, I agree that additional expansion of some topics would be nice.

                                                                    2. 2

                                                                      31 years in the industry here. You’re mostly right on all these points. In several cases you need to learn where ‘it depends…’ is the right answer.

                                                                      I’m sorry you don’t seem to have benefitted from good project management. Your next growth spurt will either come from being exposed to good project management, or suffering through a few years where you’re the bad manager.

                                                                      1. 1

                                                                        TDD purists are just the worst. Their frail little minds can’t process the existence of different workflows.

                                                                        This. I understand the value of TDD, especially as you are mostly force to apply YAGNI while doing TDD. But I’m tired of people thinking TDD is the only way to get good code.

                                                                        1. 1

                                                                          Words of wisdom. I would probably add “less is more” to the list of principles.

                                                                          1. 1

                                                                            The word “scalable” has a mystical and stupefying power over the mind of the software engineer. Its mere utterance can whip them into a depraved frenzy. Grim actions have been justified using this word

                                                                            I could quibble with one or two other things here, but this is certainly an insight I wish I could distribute to the entirety of the (depraved, reckless, morally bankrupt disaster of an) industry that is software.

                                                                            1. 1

                                                                              Adding more technology is rarely a good call

                                                                              I would love to hear elaboration on this. Also, does this include migrating to newer technology?

                                                                              1. 1

                                                                                I agree with almost everything (though I’d word things a bit more charitably, myself), but I don’t agree about product managers [EDIT: oops, I see now he wrote “project managers”, not “product managers”]. Maybe there’s a mix of good and bad ones across the industry overall, but the ones I work with in $current_employer are really good, and I would not say any of them are useless or disposable.

                                                                                Also: in my experience, I haven’t seen net gains from efforts to bring typing to traditionally untyped languages (in my case, Ruby and Javascript). It’s not without benefit, of course, but I found it just bogged me down in annoying ways, which amounted to an overall net negative.