26 ms·

Software engineering topics I changed my mind on

• tuke 6y ago
  Are the things under "Things I've changed my mind on" things you believe now, or have stopped believing? (Can't tell which way the change of mind is.)
  • dgs_sgd 6y ago
    Directly under "Things I've changed my mind on" the author writes "Things I now believe".
    • alain_gilbert 6y ago
      There is a new sentence in the "Things I've changed my mind on" section: > Things I now believe, which past me would've squabbled with: That phrase was not there originally when the article was posted.
      • tuke 6y ago
        Nice.
  • deleted 6y ago
    [deleted]
• hankchinaski 6y ago
  >Standups are actually useful for keeping an eye on the newbies. daily updates are a chore and pretty useless rather than for the "manager" who has to check on people's work. I have been in places where we had one update every week or every other week and that was the proof (along with other places I have seen) that daily update is just a waste of time. This article summarises it for me "Daily Stand-Up Meetings Are a Good Tool for a Bad Manager" [0] [0]https://www.yegor256.com/2015/01/08/morning-standup-meetings.html https://www.yegor256.com/2015/01/08/morning-standup-meetings...
• dimtempo84 6y ago
  I'm doing my best to not be an "insane weirdo" by focusing on the correctness of code, and to ignore the extra blank lines and spaces, lack of a space in between the "//" and the first word of the comment, and inconsistent camel casing in the work of some of my colleagues.
  • chenmike 6y ago
    Just use a linting tool? Using a linter allows me to care a lot about formatting (which I do) while not consuming a ton of my team’s time enforcing it.
    • dimtempo84 6y ago
      Yes, we use golangci-lint for our few Go projects, which works well. However, most of our projects are in Java, and the mistake of our team was to never have our Checkstyle break the build. So, the result is many Java repos with a variety of coding styles.
      • dboreham 6y ago
        This is just how life turns out ime. Focus on more important things.
    • dboreham 6y ago
      Then you get to have many meetings about which litter and lint rules to use.
      • chenmike 6y ago
        This is a tiny fraction of the time that it takes to comment on PRs/CLs in perpetuity. The alternative is just to literally not care about formatting which if you are able to do more power to you, but I could not imagine working on such a team. To me it’s somewhat akin to saying that all that matters in writing is the ideas, not the formatting of a document.
      • jogjayr 6y ago
• baconforce 6y ago
  Some explanation as to why the opinion changed for or against would be nice.
• DDSDev 6y ago
  > DRY is about avoiding a specific problem, not an end goal unto itself. To add on to that, I think the key behind DRY is to not repeat a concept within your codebase, and not failing into the trap of avoiding similar but slightly different code blocks that aren't exactly logically equivalent by carving up your code into nonsense. The former leads to elegant abstraction, while the latter just leads to functions with signatures like my_function(data, BITFIELD, opt1=false, opt2=true, opt3=false, BITFIELD);
  • Rapzid 6y ago
    > To add on to that, I think the key behind DRY is to not repeat a concept within your codebase, and not failing into the trap of avoiding similar but slightly different code blocks that aren't exactly logically equivalent by carving up your code into nonsense. Dry is about not repeating behavior. It's not about not repeating text.
  • etxm 6y ago
    I’ve always found DRY to only apply well to two things: - business logic - something that your extracting as a library
  • hydroxonium 6y ago
    "Single source of truth" is more meaningful than the overly simplistic "DRY". If two things are _supposed_ to behave similarly, then not having duplicate code makes perfect sense. If two things just _happen_ to behave similarly (at first), it may be a hasty generalisation to immediately refactor them to use the same code.
  • potta_coffee 6y ago
    It requires subtle thinking. Instead what I see a lot of the time is the "rule" of DRY applied with religious fervor, and it produces the kind of code I enjoy working with the least.
  • njharman 6y ago
    I tend to think of it in terms of bugs or less so, feature addition. Weighted by likelihood of bug. If there is bug, will someone have to fix it in one place. Or, remember it’s in 7 places. If later I DRY.
• mrfusion 6y ago
  I wonder why he changed his mind to these. They don’t seem that controversial.
  • coldtea 6y ago
    They don't seem that controversial? There has been endless religious wars about lots of them. To point: > Typed languages are better when you're working on a team of people with various experience levels This is the static vs dynamically typed controversy. And if you think the consensus is "types are good" today, that wasn't at all the case 10 years ago or so. > Java isn't that terrible of a language. That was (and probably still is) the knee jerk reaction of many younger devs (and some older ones) > Designing scalable systems when you don't need to makes you a bad engineer. Not controversial in itself, but tons of people do it all the time and think it doesn't apply to their case... > DRY is about avoiding a specific problem, not an end goal unto itself. Many people take it religiously... > In general, RDBMS > NoSql The NoSQL/RD religious wars were all the rage when Mongo and co first appeared (even earlier, with BS Java projects like Prevalayer). > Functional programming is another tool, not a panacea. You'd be surprised how many think the opposite...
• cbdumas 6y ago
  > Designing scalable systems when you don't need to makes you a bad engineer. > In general, RDBMS > NoSql These two bullet points resonate with me so much right now. I'm a consultant and a lot of my client absolutely insist on using DynamoDB for everything. I'm building an internal facing app that will have users numbering in the hundreds, maybe. The hoops we are jumping through to break this app up into "microservices" are absolutely astounding. Who needs joins? Who needs relational integrity? Who needs flexible query patterns? "It just has to scale"!
  • virmundi 6y ago
    Are there other constraints that might make DynamoDB a good fit? For example I made an app at a client. We could use RDS or we could use Dynamo. I went with Dynamo because it could fit our simple model. What’s more, it doesn’t get shut off nightly when the RDS systems do to save money. This means we can work work on it when people have to time shift due to events in the life like having to pick up the kids.
    • tomnipotent 6y ago
      > it doesn’t get shut off nightly when the RDS systems do to save money If your company needs to shutdown RDS to save a couple of bucks a month, there's a much larger problem at hand than RDS vs Dynamo.
      • Aeolun 6y ago
        At scale it’s a little bit more than a few bucks. Across the board, we spend hundreds of thousands on ec2 instances for dev/test, so turning them off at night when nobody uses them saves you quite a lot of money.
    • martinald 6y ago
      The problem with NoSQL is that your simple model inevitably becomes more complex over time and then it doesn't work anymore. Over the past decade I've realised using a RDBMS is the right call basically 100% of the time. Now pgsql has jsonb column types that work great, I cannot see why you would ever use a NoSQL DB, unless you are working at such crazy scale postgres wouldn't work. In 99.999% of cases people are not.
• m0ther 6y ago
  This is refreshing to read, and I don't disagree with you on any of your points. I wish you the best in your career. If I see your name again in a list of resumes someday, I'll put yours on the top. - 21 year R&D greybeard (37 years old)
• wegs 6y ago
  I predict the following changes: 1) Typed languages are worse, and you want people with high levels of competence. 2) Java actually IS terrible. You win very little by designing for incompetent coworkers. Plan for competence, and hire appropriately. Small elite teams beat large incompetent teams every time. See #1. 3) Thinking through scalability upfront matters in many systems. Not all systems. Many systems. 4) SOLID is one way to do things, and not always the right one. OO isn't always the right one either. 5) YAGNI is more complex... you shouldn't build what you don't need yet, but you should architect for reasonable changes to requirements. Scope out all possible features early in the system design, create an architecture that supports them, and then implement the minimum viable system which can be easily incrementally refactored into that architecture. 6) There are ways to interview well. When you figure them out, you'll notice they give you a competitive advantage (while sharing them doesn't make the industry more efficient as a whole, and makes them less effective, so if you're smart, you'll keep them to yourself).
  • baccheion 6y ago
    Many would desire elite teams. On the other hand, such capable programmers are not the norm. Most are stuck with what they get and have to make it work.
  • t-writescode 6y ago
    10ish years in, professionally. I agree with the official list provided by the link pretty well. edited for clarity
  • mixedCase 6y ago
    Hard agree with 4 and 5. Soft agree with 6, I think there's nothing's wrong with sharing specially since many of the important teachings are incompatible with the kind of people for whom these lessons are not obvious after a couple of years of experience. But points 1 to 3 give me a visceral negative reaction. I'll go into detail: 1) If you're writing anything that's not a script with a few lines, and you care about your software not being terrible to maintain and change for other people in real production settings, typed languages wipe the floor with dynamic languages (excluding ecosystem moats, just judging the languages). Good types act as documentation, a higher form of tests, and a form a development paradigm to make it easier to iterate through code new or old by building/modifying stacks of machine-checkable assertions that you can pass around. Not enough devs are taught how to think with types and extract the most out of them, but any half-decent dev can be taught how to do it in a few days and the difference is night and day to anyone who has experienced it first-hand. 2) Java is terrible, but it's not as unworkable as some other mainstream languages given its extensibility and ecosystem. Java was sold to managers as "prevents cheap workers from making mistakes", but it was never about that and it's mostly terrible at it. 3) I would say that's a deceitful take, for only the absolute minority of systems have to care about scaling beyond a single server with failover (and a separate database if going with managed DB). For those systems that absolutely do care about horizontal scalability the answers should be absolutely obvious to any senior dev from the moment the requirements are stated. And for those cases where someone feels there may be a need for a complex scalability solution but there's not an obvious case for it yet, development will most of the time be better off starting with the simple solution and selectively optimizing as needed, just don't make it impossible to switch later down the road.
• deleted 6y ago
  [deleted]
• bawolff 6y ago
  Usually i disagree with these types of lists, but this one seems pretty spot on. My only quible would be that only code quality static analysis is useful. Security static analysis on the other hand (e.g. taint analysis to find security bugs like XSS) is pretty overrated most of the time unless you work really hard to make it fit in your context. I also think linting rules are important, not for what they actually do, but just to get everyone to stfu about variations in code style that dont matter and arguing about more important things.
  • d3nj4l 6y ago
    Also, having consistent formatting makes it very easy to read through large amounts of code. If you know how the code is laid out, you don’t need to focus on everything and can “squint” through it to get a good idea of what’s going on.
    • Rapzid 6y ago
      I believe though that you should just have some system in place to automatically check/fix these issues(for the most part). I've been in far too many environments though where PR reviews are just surface-level formatting nits and don't address functionality or architecture at all..
    • gpanders 6y ago
      Agreed with you and the GP. In one project I’m on, I pushed for linting and formatting checks in our CI not because I’m an “insane weirdo” who cares too much about formatting, but precisely because I don’t care, I just want it to be consistent. I don’t really have an opinion about which style or format or whatever is better, I just don’t want to have to read through 6 different coding styles when I scan through my colleagues’ code.
      • SAI_Peregrinus 6y ago
        Having a consistent style enforced by an automatic tool set (linter/autoformatter/etc) means no time needs to be wasted in any given PR arguing about style, or waiting for someone to fix a style mistake. You might still waste time arguing about what the rules should be, but that's often less than the cumulative waste of fixing avoidable crap.
• the_cat_kittles 6y ago
  wise to avoid an opinion on ORMs, otherwise this would devolve rapidly. my opinion is they are potentially useful but i have never worked a job where id rather have an orm
  • brightball 6y ago
    I like them when they simplify repetitive things, require minimal configuration and are easy to get out of your way when you and the database need to have a grown up conversation.
  • silentsea90 6y ago
    I think ORMs are useful only to help provide a direct 1-1 statically typed interface to the underlying db functionality in the language of choice (example java <-> postgresql ORM) ie. select(User.UserId, ...).From(User); etc. Any more abstraction/generalization and it starts to suck. ORM for java <-> SQL databases (as a whole) are still fine as long as it allows for specialized operations on your sql db choice (say postgres specific functionality not available on mysql), but as ORMs start to get more ambitious by hiding away the actual SQL queries, things go south (looking at you hibernate). Programmers SHOULD know SQL and if they don't, they NEED to learn it. It isn't the ORMs job to abstract it away. That's a recipe for disaster
  • liamliamliam 6y ago
    You should be using both.
• baccheion 6y ago
  I dislike sacrificing purity, but I am capable of doing it. Most software is a hogpile of sh*t destined to rot. It simply won't last. Those sections that do (if it never has to be touched, it also didn't last) are usually subpar. Especially with accumulating "ship ship ship" modes, costs, and competing via speed, it'll only get worse. Most time spent cleaning up code and improving architecture is time wasted. The startup will fail, the startup will get bought and shutdown, the project will get scrapped, the service will no longer be used, etc. What little survives will be in a state of constant turnover, one that leads to the same junk. Any optimizations/streamlining/elegance would be to address near-term usability issues. That is, the code is unwieldy to adjust each day and so needs to be reworked. Otherwise, it's wasted effort. Further, if it will linger, then would be the time to clean and file away. On the other hand, companies may still fear refactoring at that time as it risks introducing bugs. Most code sections that linger are not foreseen as being worthy. By then, it's too late. Other sections never matter, as they end up untouched.
  • toast0 6y ago
    > Most software is a hogpile of sh*t destined to rot. It simply won't last. Those sections that do (if it never has to be touched, it also didn't last) are usually subpar. Look, most of my code is shit. I expect the requirements to change sometime in the next two weeks. The code isn't expected to rot, it's expected to be thrown away. Anything that sticks around longer than that isn't subpar, it managed to actually meet the underlying requirements. Anyway, if my shitty code ends up becoming a problem later; I don't have any qualms about sunk costs, because I didn't build a pinacle of architecture; and I'll probably have a much better idea of what the requirements and use-cases are. Mostly, the important thing is to reduce the amount of layers. It's a lot easier to make changes to shitty code without too many layers than polished code that has wrong or inconvenient abstractions. Of course, shitty code that's over abstracted is even worse.
• mlthoughts2018 6y ago
  The author of this seems like a real joy to work with > “TDD purists are just the worst. Their frail little minds can't process the existence of different workflows.” Imagine thinking about colleagues as people with “frail little minds.” Yikes. Many of the other points betray serious attitude and perspective problems, but it was forgivable until getting to that last bullet and realizing, no, this is just a person with a shitty attitude.
  • deleted 6y ago
    [deleted]
  • coldtea 6y ago
    >Imagine thinking about colleagues as people with “frail little minds.” Yikes. He's not thinking about ALL colleagues, but "TDD purists". And even so, it's obviously a turn of phrase to dismiss the hardcore purism, not something the author generally feels about such people in their entirety.
    • mlthoughts2018 6y ago
      Absolutely not. Setting up a strawman “absolute purist” (and yes, this is a strawman - no, you haven’t worked with real people taking the extreme strawman TDD position that could magically justify this) and then using needlessly insulting or belittling language to condemn the fake strawman is totally ridiculous. Your attempted defense of it is not acceptable. You could just as easily say something like, “People who take TDD to an extreme are hard to work with and ultimately their inflexibility and unwillingness to appreciate other approaches does more harm than good.” See how that’s not dehumanizing? See how that accomplishes the same thing without disgusting juvenile insults like saying someone of a different ideology has a “frail little mind”?
      • coldtea 6y ago
        >and yes, this is a strawman - no, you haven’t worked with real people taking the extreme strawman TDD position that could magically justify this No strawman required. There are real devs with extreme TDD zealotry. It's very possible that the author has worked with such devs, and I see no reason to doubt his experience. Your use of the word "strawman" above, doesn't magically make such devs which push TDD with zealotry as some silver bullet solution not exist. The only reasonable reading of your point then is that those devs are not enough to justify the phrase "frail little minds". It would take some far more extreme, non-existent in the world, level of TDD zealotry (what you call a "strawman TDD position") to justify sthe use of a phrase. But that's just you setting an arbitrary criterium. Which neither the author, nor I share. I'm fine with using the term "frail little minds" for people with real-world levels of TDD zealotry. I furthermore understand that it's just a phrase used by the author to refer to devs that can't get over their (real world level) TDD zealotry, that it doesn't imply anything about them otherwise, and that it's not a big fucking deal. >See how that’s not dehumanizing? No, I fail to see how the authors turn of phrase was dehumanizing. I leave such characterization to actually dehumanizing things, for example racism.
• runawaybottle 6y ago
  Damn, I usually don’t agree with every bullet point in these lists but I agree with everything here (even the last bit about the weirdos). Is the OP me?
• datascience91 6y ago
  According to the author, FP is another tool. No, Functional Programming is NOT a tool but a paradigm which is a formal system of computation based only on function called lambda calculus.
  • coldtea 6y ago
    Point (of the author) proven.
  • mixedCase 6y ago
    A programming paradigm, or in plain english: a way of thinking and stating solutions to problems, is just a tool. Just like OOP is just a tool and procedural is just a tool. I'm in the camp that FP should be the default tool for expressing business problems, jumping down to procedural or OOP for caring about some kinds of low-level details, but it does not make it anything other than "just a tool".
    • datascience91 6y ago
      Not sure if I follow you. I thought a tool != an abstraction According the English dictionary A paradigm is a standard, perspective, or set of ideas. A tool a piece of equipment == something is concrete Can a mathematical expression or equation be considered a tool?
      • bcrosby95 6y ago
        People regularly say "the right tool for the job". When it comes to software that can mean any decision you make on what to use for solving your problem: language, OS, IDE, editor, architecture, low or high level design, etc.
      • AnimalMuppet 6y ago
        You sound either like English isn't your first language, or like you're taking words far too literally. In the sense we're using, a tool is anything we use to do what we're trying to do. A physical tool is a tool. A software tool is a tool. But if I'm trying to ship something, FedEx and UPS are tools (in this larger sense). So an abstraction, a way of thinking, a way of writing code, is also a tool. I can use FP for the problems that it fits well, and use other ways of programming on other problems. "It's just a tool" means "it's not The One Right Way". Use it when it fits. Don't use it when it doesn't.
• baby 6y ago
  > YAGNI, SOLID, DRY. In that order. What? > Java isn't that terrible of a language. Doesn’t mean it’s a good language though. > Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers And when people ask for numbers, it is usually because they don’t like your idea > People who stress over code style, linting rules, or other minutia are insane weirdos That’s why you need languages with good defaults for formatting and linting (e.g. Go, rust) > 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I admit I still don’t understand what a PM really does.
  • zaphar 6y ago
    YAGNI: You aren't going to need it.\ http://c2.com/xp/YouArentGonnaNeedIt.html http://c2.com/xp/YouArentGonnaNeedIt.html SOLID: A long list of architectural principles https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID DRY: Don't repeat yourself A set of useful principles in software architecture. I mostly agree with his order too.
  • dathinab 6y ago
    > I admit I still don’t understand what a PM really does. In the best case they have a proper technical understanding and do ground the team in reality (i.e. makes sure the team doesn't over analyses/engineer and adds fully unnecessary part). Then the PM should help the team to come to decisions if the team can't decide weather they do solution A or B and they _seem_ to be equally good wrt. all measurable and non measurable aspects. Lastly the PM should help to keep all the unhelpful and hinder-some things upper management might want to put on the engineering team away and similar thinks. The problem is the PM needs IMHO solid technical understanding of the topic in question at the same time they need enough soft skills to nudge the team in the right direction and protect it from upper management absurdities. I don't think I have yet to meat a person who fulfills this qualities, often they fundamentally lack technical understanding to a degree that they do more harm then good, i.e. in many cases a self managed team with a tech. senior team lead is a better problem. Except if the team lead is not grounded enough and prone to over-engineering, at which point a PM (or second team lead) to ground this person is essential.
• gameswithgo 6y ago
  >Java isn't that terrible of a language. That is going to evolve in the next six years to "languages don't usually matter much except in specific domains in a few cases"
  • bawolff 6y ago
    ? That seems like a rather silly prediction. There is enough code written in java that even if people stopped writing new java this instance, it would still matter across a broad field of domains for more than the next 6 years. There is a world outside of what languages are trendy on hn right now.
  • sk5t 6y ago
    Except when you care about the ecosystem, build tools, willingness of the rest of the team to maintain the codebase, etc.--so the language usually matters even if you're not religiously dedicated to one in particular.
  • naikrovek 6y ago
    I'm not sure about that. As an industry, we're just beginning to realize that object orientation is hurting far more than it's helping. As more people realize this, better tools and techniques will be devised to help developers think of their programs more like computers do: as data, and not as objects which only make sense to some humans. As such, PURE OOP languages like Java are going to start to fall out of favor in the industry for all workloads. Academia won't let go of OOP until much later.
    • potta_coffee 6y ago
      I hope Java and .NET fall into disuse, I've never enjoyed programming less. I'm not a fool, I recognize that some great software can be created with those tools, but it just feels so much more painful to work with. It must be my taste.
  • valenterry 6y ago
    If this were true, it would make no difference if one uses assembly or Java or use a magnetic needle to swap bits. But it's clear to everyone that it makes a big difference. If someone says "language doesn't matter" it usually means they suffer from the blub paradoxon.
• naikrovek 6y ago
  > So called "best practices" are contextual and not broadly applicable. Blindly following them makes you an idiot That's the truth. "Best Practices" often force you to ignore what your problem actually is and view it in some twisted way that fits the practice. Bad. Your problem is your problem. Your data is your data. Write code that matches what you have and what you're trying to do.
  • t-writescode 6y ago
    My biggest frustration around ‘best practices’ is when you’re tasked with learning a new framework to consider adopting it for the company and you’re given a week and they want ‘best practices’ to come out of it. There is no way I can learn how to write good code in a completely new framework that everyone should model after from that. I can show what worked for a toy problem and something that’s hypothetically similar to a real problem, but that says nothing of real complexity or practices that are actually going to last more than a few months on the project.
    • dathinab 6y ago
      > learning a new framework to consider adopting The best practice is to not learn a new framework. Only learn the new concepts (technical and UX, if there are any) and if there is no noticeable benefit do continue using old framework. In many cases new frameworks do not bring improvements to a degree that switching is worth it. They often do either obfuscate it or don't realize it themself, but most new frameworks do not invent any new concepts, they just dress existing (often old) concepts in new clothes. Which sometimes _can_ be a major improvement of UX but very often are not.
      • t-writescode 6y ago
        In the specific examples I’m thinking of, it’s transitioning from a single-threaded, non-async infrastructure to a multi-threaded and async infrastructure in a new language. We had to learn a new technology stack for that; and, frameworks, among others, are a required step in that. I’ve also had to do “best practices” around things like introducing grafana or whatever to our stack, and what the metrics should look like.
• throwawayboise 6y ago
  Coming up on 30 years. I agree with most of your observations except standups. In my experience daily standups are a waste of time. Maybe I've just had bad luck with them?
  • silentsea90 6y ago
    10 minutes is hardly an investment in both ensuring devs share a goal they're committed to at the start of the day, and that devs aren't going down the wrong path, and people are in sync. I have had many standups where days of person X's time was saved by person Y offering a suggestion on how to do a certain task. Don't let a standup go beyond 10 minutes. X and Y in the above example should sync after the standup separately in case their discussion is longer than the duration of the standup
    • joseph_grobbles 6y ago
      "10 minutes" Are you the only one attending or something? Standups are initially scheduled for the start of the development day. But then people come in a little late, get that first minute call, have to attend to something that hiccupped, so soon enough the standup happens 30 minutes into the day, eventually an hour into the day. So if you did get there on time, now you just spin your wheel waiting, because first you've got that obnoxious standup that's going to disrupt everything. Now you get there and spend ten minutes waiting for everyone to assemble, and for the S.C.R.U.M.Master to pull Jira up on the overhead. Finally you get going and everyone has an essay about their herculean effort putting a button on a form, which absolutely no one is listening to. You have the manager (because really they're a garbage way of managing) interjecting and asking questions. You have someone say something dumb they're doing and everyone gets to stand there while two people who could have taken it offline have a conversation. 40 minutes later you go back to your desk. Invariably the standup aficionados (almost universally shitty managers) will say "you're doing it wrong!", but what I just described is the standup reality virtually everywhere. EDIT: Exactly as expected, I made the mistake of actually replying to people who questioned my comment, which means when some angry person comes along they get to downvote all of them. That aspect of HN is weak sauce.
• foolfoolz 6y ago
  > 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. it’s unfortunate you haven’t had the opportunity to work with a strong product team. i agree when they are not helpful it’s a negative impact on the team. but a great PM can elevate everyone who develops that product
  • blevinstein 6y ago
    Product manager and project manager are different roles. I think the author was specifically designating the latter.
  • username90 6y ago
    > it’s unfortunate you haven’t had the opportunity to work with a strong product team. He said that 10% were useful, not that all of them were bad.
• ng12 6y ago
  > 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I was just thinking about this. Most PMs remind me of that scene from Office Space: "Engineers are not good at dealing with customers. I have people skills!". There's no need to insulate engineers from the products they work on and the customers they work for. Good engineers want ownership, let them have it. A big part of the problem in my experience is that PMs tend to proliferate. I've seen many startups go from hiring their first "product" person to suddenly having a PM team that's a third the size of engineering.
  • 01100011 6y ago
    In my experience, a PM handles a lot of the crap work that engineers shouldn't be working on. A PM keeps management apprised of progress. A PM handles the work involved in keeping Gantt charts up to date. A PM coordinates with dependents and dependencies to make sure resources and components are available when needed. If you don't appreciate the value of that, you maybe have worked on smaller projects or not been in a large org that pushes those menial tasks onto engineers. PMs are there to facilitate engineers. They do not rule over them. They make targeted, efficient queries of engineers' status and then communicate and coordinate appropriately. I would love to see PMs hired at my org. We're currently drowning in process-related tasks and it's mostly because we do not have PMs(the process is mostly necessary, but wastes engineer time). I'd also love to have some technical writers on staff. Having engineers write documentation, beyond, say, doxygen comments in header files, is just dumb. Right now our user facing docs have little consistency or defined scope. They don't target a well defined audience, and don't effectively communicate to our users. Let engineers do what they do best, and enable them to be productive by hiring helpers as needed.
    • ng12 6y ago
      If you're hiring more people to deal with rote, managerial "process" you're already lost in a mire of inefficiency.
    • kazamaloo 6y ago
      We used to have 3 PMs in our team of 20ish people. Two of the PMs left and NOTHING changed for us or our project. The idea of being relieved of process-related tasks is nice, but it rarely happens. You get pulled in to those timewasting meetings by your PM anyway.
• woeirua 6y ago
  The insane obsession with scaling is killing this industry. So much effort is being wasted trying to use NOSQL or K8s at companies that have DAU counts in the low hundreds. Absolutely asinine.
  • sanderjd 6y ago
    But is their business model targeting hundreds of DAUs, or is it targeting millions of DAUs? It doesn't make sense to architect for an amount of usage that is too small to sustain the business. If the business model requires millions of users to be successful, you should build for millions of users, even if you only have hundreds at the present moment.
    • lolinder 6y ago
      If you build for millions of users the way most devs do, your business will flounder before you finish. Facebook, Twitter, and Google all started simple and scaled only when it became necessary. If you want to do what they're doing, start by doing what they did. Don't skip to the microservices.
      • woeirua 6y ago
        This is exactly right. Prove your business with the bare minimum tools required and then when you have enough paying customers go out and hire lots of engineers to figure out how to make it scale.
      • sanderjd 6y ago
        We don't actually disagree, but I believe Twitter is actually one of the cautionary tales. Their product went through a long period of stagnation because they were too busy toiling at scaling. Same thing seemed to happen to Github, from my perspective.
    • danfang 6y ago
      The reality is that companies at an early stage don't have validation of their idea yet. That is priority #1. The scaling part comes only after you know your idea has merit. It's also "the easy part". With the right allocation of resources and talent, most scaling challenges can be solved. The same cannot be said of creating valuable / interesting products. The right approach is to optimize for speed and flexibility. Make it as easy as possible to validate your idea. Make it easy to tear down and rebuild in a "scalable" way if you're lucky enough to make it past step #1.
• pdimitar 6y ago
  > Functional programming is another tool, not a panacea. That's extremely true and I am not denying it. I'd like to add the nuance that us the Homo Sapiens seem to operate better when we are pushed into the right direction. Giving us too much choice -- like global mutability and OOP in general -- can cause analysis paralysis and make people do all sorts of panicked dumb choices in their software projects. As a guy with 19 years of experience I seriously wish I could forget some of the codebases I had to inspect. So while FP is just another tool, it's also a framework for thinking that helps people make better choices. Same goes for static strong typing.
  • adamkl 6y ago
    > So while FP is just another tool, it's also a framework for thinking that helps people make better choices I’ve been getting more into functional programming this past year (via Clojure, though my day-job is mostly JavaScript/TypeScript) and this is the big takeaway for me. Type theory and monads may have their place, but thinking about separating logic from side-effects is, I think, the most valuable aspect of functional programming. That is a thought process that you can apply in pretty much any language that will give you the biggest bang for your buck. Edit: Here’s some great examples of the benefits of functional thinking without going off the deep end. 1. Boundaries by Gary Bernhardt - https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries 2. Pits of Success by Mark Seemann - https://youtu.be/US8QG9I1XW0 https://youtu.be/US8QG9I1XW0 3. Grokking Simplicity by Eric Normand - https://grokkingsimplicity.com/ https://grokkingsimplicity.com/
    • pdimitar 6y ago
      Yep, there also exists such a thing as "I learned language X and will not use it for my paid work but it made me a better programmer". One such example for me is Racket.
      • busterarm 6y ago
        Free Pascal. That said, I'll use anything in my paid work if the project is interesting enough. Hence the three years I spent writing PHP.
• BobbyJo 6y ago
  11 years in and my one critique is: >Designing scalable systems when you don't need to makes you a bad engineer. You have to have a very good understanding of the 'need' ahead of time or you're effectively just playing a kind of lotto. Do the bare minimum and it meets the need, you win. Do the bare minimum and it doesn't, get ready to start over, you lose.
  • ZephyrBlu 6y ago
    You can do the bare minimum with a path to scale, though. But it seems like when things 'scale' a lot of changes are required regardless, so I feel like it's a bit of a moot point.
    • BobbyJo 6y ago
      Plus, 'scalable' can refer to the codes performance or the codes malleability, and the two are often conflated in blog posts :P
  • jackcosgrove 6y ago
    You can hedge by breaking up your codebase into logical services from the start which own their data sources and controllers. When the time comes to break up into microservices, you separate each service into its own application rather than grouping them in a monolith.
    • BobbyJo 6y ago
      Writing services in a separable manner is, in a sense, writing scalable software.
      • jackcosgrove 6y ago
        Write the microservice, deploy the monolith. You can save on hosting costs. It's not perfect, no.
  • potta_coffee 6y ago
• aerovistae 6y ago
  Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently looking for a solution to Y" and for M to say "Oh I had to solve that same problem last month!" Seniority has nothing to do with this. Communication/coordination/knowledge-sharing matter at all levels.
  • H8crilA 6y ago
    It's especially useful with the newbies, as they are most likely to attempt to reinvent the wheel, due to lack of knowledge/experience. Also, in the age of WFH stand-ups are a replacement for lunch conversations, the most rudimentary block of team building. I think that if you're not doing stand-ups or something like that since March you're probably losing team coherence.
    • austincheney 6y ago
      There is not much wrong with reinventing the wheel. It is a less efficient use of time that often results in a beneficial serendipity. The opinion that reinventing the wheel is somehow a supremely evil satanic ritual is what prevents original solutions and allow expert beginners to become shitty decisions makers.
      • Twisell 6y ago
        You are totally right but probably assuming you have a top notch and easily discoverable documentation that can guarantee that newbies won't spend 15 days reimplementing "that bash script you need once a year or so" that do the job in 2 minutes. However even if this case you might get lucky and end up with a new script that do the job in 30 seconds and everybody in the team have learn that documentation is very important.
        • 6y ago
• madeofpalk 6y ago
  Not totally enthusiastic about this type of developer who disses other professions.
  • username90 6y ago
    Recognizing that other professions have just as many charlatans as software engineering, just that they are harder to weed out, doesn't mean you "diss" other professions. Every role is important, but not every person working in that role can actually do the job properly.
• matt2000 6y ago
  I am around 20 years into professional software dev and this list is great. Not sure what else I can add, just wanted to +1 the whole thing basically.
• Grimm1 6y ago
  I think I love this person.
• cbm-vic-20 6y ago
  I'm at year 25, and I agree with this list. And I wish more people who think I'm too 'old' agree as well.
• dantodor 6y ago
  After 35 years, my opinions are mostly the same.
• baron816 6y ago
  I think this makes for an EXCELLENT interview question. Engineers with strong opinions are better than engineers who just do whatever others want and haven't thought deeply about anything. But even better is an engineer whose opinion changes as more information becomes available. You want to hire the person that is capable of both making a thorough case for one approach, and is mature enough to admit that that approach is suboptimal and then go implement the optimal one.
• danfang 6y ago
  I agree with most of the points the author makes. > Pencil and paper are the best programming tools and vastly under used I'm not convinced of this one. I grew up with digital tools only. Can someone give me examples where this assertion is true?
  • smallnamespace 6y ago
    System diagrams. I've never drawn seen anyone draw a system diagram using any tool more quickly or better than they could on the back of a napkin. If you start from the get-go trying to wrangle a UML diagram or Lucidchart, then your mind is immediately guided to do only the things the tool makes easiest. That's why when you're inventing something from scratch, a pencil and a piece of paper are best. Of course, if your handwriting is messy, go back and use a tool later for your colleagues' sake.
  • surprisetalk 6y ago
    In my experience, pen-and-paper helps me resist the urge to “just get started already”. I don’t know why, but when I’m in the design-phase with a keyboard in my hands, I think I get too excited about building things and go straight to the text-editor to “hammer out the details” in code. Away from the computer, I’m much more likely to complete a thorough design. And pen-and-paper remains my favorite tool for working on ideas that are too big to fit in working-memory.
  • roganartu 6y ago
    > I grew up with digital tools only. This implies that you exclusively use digital tools, so my first question would be: have you tried using pen and paper for things? It's really hard to give compelling examples of where pencil/pen and paper are going to be better than digital tools because everyone is different. If you want to try it out, I recommend simply keeping a pad and a pen at your desk and when you're stuck on a problem try writing something down. Whether it's mapping it out, quickly jotting down some assumption or thing you noticed etc. It won't be suitable for everything but there's something... visceral about writing with a pen that I find indescribably helpful in working through complex problems. This was how I got started with this process, at least. For a more concrete example, I spend a lot of time in my current role thinking about high-level solutions to problems. Things that need to serve multiple different teams' needs, replace existing solutions (aiming to solve their most obvious pain points), sometimes have non-obvious simple solutions, legacy complex solutions that everyone is used to and just kind of accepts etc. These designs come from months of discussions with different people, thinking, theorising, research into existing solutions etc, but one thing I have found absolutely invaluable throughout this process is the pen and paper on my desk. My notebook is full of unorganised notes that I jotted down when a lightbulb came to me one day, rough sketches or mappings of solution ideas, brainstormed lists of features etc. Most of these don't see the light of day, but as they get refined they move to more permanent, collaborative (as necessary) mediums. I do this progressively by flipping back through my physical notes and reviewing/extending/transferring them as necessary.
• dnautics 6y ago
  Here's what i have to say about TDD (I do not practice TDD on a day-to-day basis). Even if you don't use it, you should know what it is. If you choose to use it religiously, that's probably a bad choice, but if you don't do it ever, you are missing out on a huge tool. In general, if I see an insurmountably complex challenge ahead of myself, sometimes TDD (especially detroit-style TDD) is a tool to refocus my attention and implement the minimal implementation and move past goals. Also, doing test-heavy development (which TDD gives you for free) gives you insight into how that break/fix loop can supercharge your productivity by giving you those dopamine rushes as a reward for your effort.
  • Aeolun 6y ago
    I think the best part of doing test driven development (or similar) is that making your code easily testable generally also makes it architecturally sound.
    • dnautics 6y ago
      Refactoring is quadratically more difficult if you don't have tests.
      • mbeex 6y ago
        Not this simple. Refactoring might mean invariance, but the more comprehensive your tests are, the more they also test the moving parts. That means, they have to be changed too. Many people forget the maintenance costs (and this has a much broader meaning than the refactoring example). Tests themselves have to be considered as a software (or more general) artifact with a cost.
        • vendiddy 6y ago
          For this reason, I prefer going heavy with integration tests early in in a design. This way I'm not rewriting tests every time I need to rip apart and restructure the internals but I still have the safety net of refactoring without breaking the external contract.
• hertzrat 6y ago
  > People who stress over code style, linting rules, or other minutia are insane weirdos Really great post, although I do really value good, consistent code style. Readability really matters (imho). You can even use writing concepts like parallelism if you are feeling fancy to make things even easier to read.
  • aero142 6y ago
    I don't understand this claim of readability. If it were true, then you wouldn't be able to read a code base with a different code style. In truth, the switch takes about 10 seconds for me to get used to. Which is about 10,000 times less that the time I've wasted debating code style with other developers that insist that "consistency" is a useful goal without justification. There is exactly one concrete goal that I have found. Keeping people's editors from fighting each other in editing the same file. Other than that, just let it go. I've switch everything I can find to the automated formatters so that I never have to listed to someone complain about formatting again.
    • t-writescode 6y ago
      Cognitive load is real and that 10 seconds is more load you have to put onto your mental ram to get anything done. It’s easy to not notice it until it’s not. That’s why autoformatters are better in general. There’s no argument, it’s just how it is, and it’s dealt with.
    • psyc 6y ago
      I have no problem diving into a new code base on a new team with a style that’s unfamiliar. I absolutely do not want to switch styles as I work on the same project. I don’t much care what the style is. Successful implementations I’ve seen include: tasking one person to pick a style, then allowing exactly one meeting in which to iron out the quibbles. Or, literally googling for a style recommendation and just choosing one of the top results, as is, no discussion. I agree that the endless religious arguments must be avoided. All the more reason to seek a strong manager and / or tech lead.
• bshoemaker 6y ago
  > 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I never cease to be surprised when an otherwise intelligent person lays judgment on something they likely do not understand. At larger companies, these types of roles are invaluable. I'm going to charitably that this isn't referring to product management - it's dumb either way though.
  • era86 6y ago
    This developer only has about 6 years of experience working at Amazon. It seems surprisingly naive how little this person understands about what a decent PM shields them from as an engineer, but I've heard working at Amazon sucks altogether. So, par for the course?
• loosescrews 6y ago
  Test driven development requires you to have a spec upfront. When you already have a testable spec, test driven development seems to be a net positive. It can be a good way to explore the spec before building the implementation. At the same time, you shouldn't force yourself to write all of the tests up front; additional tests will typically occur to you as you build the implementation. If you don't have external factors forcing a spec, I feel that test driven development is a net negative. Forcing a spec up front often requires making decisions before you fully understand the problem. Once you have tests, you have invested in the decisions and are less likely to reconsider them when encountering things that should have influenced the design. On a related note, most interfaces, particularly internal interfaces, should be influenced by the implementation to keep the implementation simple. Building a simple yet comprehensive solution typically requires a full understanding of the problem.
  • jdlshore 6y ago
    > Test driven development requires you to have a spec upfront. What? TDD was created by Kent Beck as part of XP, which is about as far from up-front design and spec as you can get.
    • loosescrews 6y ago
      How can you write a test for something that doesn't exist without deciding how it is going to work before building it? Tests are a form of a spec.
      • deleted 6y ago
        [deleted]
      • jdlshore 6y ago
        Either you’re making a point that’s technically correct but missing the point, or you’re misinformed about how TDD works. TDD is an iterative process that generates tests and code at the same time, in very small (1-5 lines of code) bite-sized pieces. Although it could be argued that tests are specs, they don’t happen up front.
• etxm 6y ago
  > Pencil and paper are the best programming tools and vastly under used I do most of my large work (not small features) on paper first in pseudo code and drawings. It helps me think through a problem rather than code through a problem. The TDD one seems directed at someone. I was really anti-TDD until I lost a bet with a lead on my team about 15 years ago. I tried it for a few weeks and it really changed the way I develop - and I started delivering code faster (this was the bet). Now-a-days, I don’t always write tests first. I definitely fool around or cowboy code sometimes especially when working with something new. Once I’ve figured out how to use the API, tool, or library; I delete my code and write tests to work through what my API will look like, then write my code.
• tcbasche 6y ago
  The TDD one I sort of half agree with. Purism and zealoutry are rarely a good reaction to anything, but I've seen a lot of dodgy code that, if it had been written with at least testability in mind, or with a test first it wouldn't have been half as dodgy.
  • bear8642 6y ago
    >test first it wouldn't have been half as dodgy. Feel part of this, in my very little experience, is with tests focus is getting smallest thing working so less to go wrong
    • tcbasche 6y ago
      I think another commenter said something poignant around this as well; it’s great too if you are working to a spec. For exploration it might be a cumbersome approach to go all in with.
  • tonfreed 6y ago
    I tend to do TDD because I hate having to pull up a full application, run the thing and then eyeball a result. The problem with TDD zealotry is that often they'll induce all sorts of architectural rot (DHH did a thing on test induced design damage a while back) in the name of testability
• potta_coffee 6y ago
  Well hey, the opinions are mostly my own, with the exception of standups. Newbies should probably have a mentor / shepherd that communicates with them directly and often.
• cccc4all 6y ago
  It's good list. Except the TDD rant. TDD can be reframed as codified specifications with test verifications. Then, the TDD purists do have a point.
  • t-writescode 6y ago
    Then it’s not (edit: pure) TDD. The TDD purists I’m familiar with think if you write any code before you write the tests, you’re doing it wrong.
    • jdlshore 6y ago
      That’s a common misunderstanding of TDD, but it’s incorrect. TDD is an incremental cycle of write test, write code, refactor, repeat. Typically less than 5 lines at a time.
      • t-writescode 6y ago
        Given the order of the words you said, writing tests comes before writing code, as I said.
        • jdlshore 6y ago
          Writing one test comes before writing a few lines of code. It’s iterative. Tests (plural) don’t come before code. They happen at the same time.
• noisy_boy 6y ago
  Regarding testing, I've noticed that every time I've thought I've done enough manual testing (and I do a lot of that before I push to QA) and I can add the automated tests "later" due to time crunch or whatever, I've found issues when I got around to adding them. This experience has fundamentally changed how I view automated tests.
• vmception 6y ago
  > 'agile' / 'scum master' driven waste of everyone's time please don’t correct this spelling
• vmception 6y ago
  > Designing scalable systems when you don't need to makes you a bad engineer. > In general, RDBMS > NoSql I use NoSql because RDBMS is a premature optimization for me My experience with ORMs especially ORMs I didnt chose is that they are frail, assume too much and I often end up writing my own plain text queries anyway, all so that I can get a result from the database in object form, but without bogging down the database with inefficient queries NoSql is object and collection based by default, and any Orm-like necessity is standardized with that database, instead of with a third party under-maintained library My projects dont need to brag in an engineering blog about scalable performance, and the memcache solves all bottlenecks I’ve ever encountered
  • beagle3 6y ago
    The problem you point to is the ORM, not the DBMS. And if you think “of course, but how can you OOP properly without objects? (And thus ORM if you use an RDBMS)” — you might join some of us in the conclusion that OOP is way overrated. Don’t get me wrong, it is exceptionally useful when it’s a natural fit, like in GUI systems and some aspects of game programming. But in many places, it is completely unfitting, and complicated things (similarly for FP, BTW)
    • vmception 6y ago
      My point is that I dont need to do plain text queries or need to make queries simpler or worry about what I just did to a row when I am using NoSql Whereas I have all those concerns with DMBS, the ORMs want to help but just add more problems
      • beagle3 6y ago
        Having used ORMs, SQL and NoSQL, My experience is that NoSQL is basically never the right choice for anything. It saves you minutes in the beginning in return for hours within a week’s time, then hours in return for days, then it just keeps costing. Especially since Postgres supports JSON properly, I’ve found no reason to use anything else except perhaps when you want eventual consistency, which couchdb may do better out of the box, but is a whole big can of worms. Added: I find DALs are the only acceptable layer over relational data, and other than BLOBs (which unfortunately no database seems to deal with nicely, and are thus relegated to the file system), everything that fits into a NoSQL fits at least as well into a modern RDBMS (e.g. Postgres)
• thayne 6y ago
  > Java isn't that terrible of a language True. It isn't a great language, but isn't terrible. What is terrible are the over-engineered, over-abstracted APIs that are relatively common in the Java ecosystem.
  • mewpmewp2 6y ago
    What I hate is that I can't understand anything when I try to understand existing code with all the abstractions going on and having to jump through 100s of files with so much boilerplate and clutter, trying to understand how the logic binds together. And then just interfaces everywhere, I can't even jump with an IDE, I have to find where this interface magically gets injected first to find the actual logic. Also I guess I don't like massive slow IDEs and slow compilation times. I just feel so slow when working with Java as well my mind gets distracted and frustrated. Maybe it is my personality flaw to not have that type of patience.
    • beagle3 6y ago
      Structured programming saved us from “spaghetti code” but Java culture introduced “spaghetti class hierarchy” and practitioners seem to practice it quite religiously.
  • rebeccaskinner 6y ago
    This was probably the one bit that I really disagreed with. I've never been a Java developer, but I've had to touch it a few times in my career, and have quite happily left very well paying jobs for lower paying jobs just to avoid having to write more Java. I can't rightly think of any language I would plausibly have to use in industry that I find more unpleasant than the Java and the entire JVM ecosystem (disclaimer: I've never used PHP). I'll buy that Java might, in purely technical terms, be not that terrible of a stack, but it's just so deeply unpleasant to use, such a profoundly nightmarish vampire of morality, so utterly and irredeemably cruel in it's ability to strip all joy out of the art of software development, that I can't possibly agree that it "isn't that terrible of a language".
    • 6y ago
• kstenerud 6y ago
  At year 15 or so, he'll change his mind about project managers. Project management is one of those broken things in the industry because it's never taken seriously. People promoted to PM generally receive no training or mentorship. In fact, sometimes the only way to break into management is to quit your job and start somewhere else with a slightly exaggerated resume. And sometimes the only qualification required is a desire to give it a try. So you have an entire class of people whose skills follow what you'd expect in a task with no discipline or training, with 50% of PMs moving the needle in a positive direction, and 50% in a negative direction (to varying degrees like a bell curve). Roughly 25% of them are people you'd actually like managing your team.
  • chime 6y ago
    Agree wholeheartedly. > 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I read that and instantly thought "yeah but which 90-93%" because the 7-10% that are great are not easy to differentiate on paper. And this can easily apply to most auditors, QA, or sales folks too. The ones really good at their job are hard to find and the rest are just being asked to do difficult things with little resources.
• commandlinefan 6y ago
  > TDD purists are just the worst No, the worst are the people who never produce any tests (or even anything testable).
• jackfoxy 6y ago
  Stick with languages, tools, and techniques that respect the math theory. Category theory, type theory, set theory, relational algebra, 1st order predicate calculus, 2nd order predicate calculus. The OP has intuitively gravitated to this side. Theory isn't going to have an answer to every question, just don't willfully oppose it. Everything else (best practices, fads, etc.) is a convention at best, sometimes useful, but should never be regarded as having special significance. And in this regard, don't micro-services fly in the face of Occam's Razor? Or as the OP stated Monoliths are pretty good in most circumstances
  • sam0x17 6y ago
    This is why I lean towards serverless monoliths these days. It works great.
  • rebeccaskinner 6y ago
    In a lot of cases Microservices are the cheaper option. Keeping your code in a monolith requires a lot more investment in tooling (to manage a large monorepo, because apparently our industry has collectively forgotten that you can actually build separate libraries and keep them in different repositories) and coordination between multiple teams working on a single large project. The simplest solution is often for management to throw their hands in the air and let each team stake out their own territory and own their own services. You certainly pay a cost for it in terms of overall infrastructure complexity, but maybe if you're lucky you get some resilience and scalability out of it.
    • ozim 6y ago
      That is what I am usually annoyed by when reading discussions like that. Someone assumes a context and throws in his experience like it would be applicable to every company and every project. Using their own definitions for industry buzzwords and by that making it more confusing for others, where those others start doing the same again as a response which brings nothing to the general understanding of things. When reading article I assumed author was not going to tackle project with multiple teams. I expect he was writing about a lot of projects that don't ever live to need more teams. You have a lot of projects where you have 10-15 devs as one team on it and those are huge projects but there are no downsides of a monorepo because it still works fine and is single repo/application. I would say monorepo should be defined as: repo where you have all projects for a company that don't need to be linked in any way. Because what I understand gave start to the term was Google having such use case, where they wanted ALL things in one repo. Having one project in one repository cannot be named "monorepo" that is just normal repository and that's what monolith in a single repo is.
• trentnix 6y ago
  90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. Manager and sometimes dev lead here. I agree with this, but would qualify that it’s not because teams are “self-organizing” or self managing or whatever claptrap the consultant sells. A good manager - or better said, a good leader - can make a massive positive impact on the efficiency and quality delivered by a team. There is a massive absence of good leadership in the software industry. All manner of process and certifications and other bureaucratic scaffolding have been invented to try and work around the absence of leadership, to little avail. Make no mistake, those practices and processes and certifications can help good managers become better. But they don’t turn bad managers into good managers and don’t compensate for an absence of leadership.
• tzs 6y ago
  > Typed languages are better when you're working on a team of people with various experience levels. Even if you are working alone you should probably treat it as working with people with various experience levels if it is code that you are going to have to periodically deal with in the future. When older you has to come back to the code, older you should be more experienced that younger you in general, but older you will also likely have forgotten much of what younger you was thinking when younger you wrote the code. In effect, older you and younger you are a team with various levels of experience.
  • ineedasername 6y ago
    Older me is continually pissed off when I encounter something clever that younger me did. I've tried to be less clever over time.
  • mewpmewp2 6y ago
    I think using typed languages can still be good even if alone assuming you are experienced enough with it, you are more likely to write everything correctly on the first try, but some other things like writing good commit messages and things like that I never do. I have never made use of git history to debug some personal project of mine.
• scrozier 6y ago
  I’ve got 40 years in the software biz. This is an excellent list, and the author is very fortunate to have gotten to this point so fast.
• woutr_be 6y ago
  > Clever code isn't usually good code. Clarity trumps all other concerns. I'm glad I'm not the only one who thinks this way. I've had countless arguments with colleagues about this, and they always made it seem like I was the crazy one for thinking this. They would often optimize or use clever tricks in their code, to the point that unless you asked that specific engineer, nobody would understand it. In most cases, the performance benefits you get from that don't outweigh the negative impacts.
  • xmprt 6y ago
    Clever code that's actually significantly faster is fine as long as you document every single thing that's clever about it, even if that means writing 20 lines of comments for a 2 line function. The worst thing is someone who writes a clever one liner without any comments because that would "ruin" the elegance of the one liner and because their code is "self-documenting"
    • woutr_be 6y ago
      > The worst thing is someone who writes a clever one liner without any comments because that would "ruin" the elegance of the one liner and because their code is "self-documenting" Sadly this was some of my colleagues, no documentation and clever one liners without comments and often obscure naming conventions. And again, we didn't need the performance benefits for our use case. I think in the end it was just a play to keep some people employed, because without them we wouldn't be able to work on this part of our application. Sadly for them the business decided to outsource and they ended up being forced to switch teams.
    • njharman 6y ago
      Faster code is not fine. Faster code should only be written after finished product is shown to be too slow for purpose and after profiler has shown which parts of code are worth optimizing.
      • username90 6y ago
        You should always have a good idea of what part of the codebase will be the bottleneck when you write it. If you have that just optimize the things it spends time on. The only time you really need a profiler before optimizing is when you are micro optimizing to try to handle cpu ordering etc, other than that performance is mostly predictable.
• tasty_freeze 6y ago
  > People who stress over code style, linting rules, or other minutia are insane weirdos I'm less concerned about which coding style, but it is important that everyone (mostly) follows the same coding style. Not all coding style rules are minutia. I've worked on code bases which have a mix of hard and soft tabs, with tabs sometimes mixed in the middle of the line, not just at the start of line, and where different authors use tabstop=2 or 3 or 4 or 8, all in the same file. And comment lines that are more than 400 characters wide.
  • beagle3 6y ago
    This is completely and trivially solvable via a checkin filter that refuses tabs (or expands them to a given number of spaces). Why fuss about it?
    • tasty_freeze 6y ago
      Why a fuss? Because some people think their choice to use hard tabs and a given tabstop setting are right and refuse to allow autoformatting tools or even just a hard tab replacement. Or they might argue: sure, the formatting is a mess, but if we reformat the code it will make tracing version control blame logs more difficult. 35 years ago, a friend told me the he and the other guy working on a piece of code would play tug of war with their shared files. My friend would replace tabs with spaces whenever he had to edit a given file, then the other guy would replace leading spaces with tabs whenever he edited a file.
      • beagle3 6y ago
        You can easily set a server-side commit/pre-receive hook that would enforce any specific agreed upon standard. Anyone who isn’t a team player, doesn’t get to commit (open source) or paid (commercial / closed source). It is one of those occasions that a 5-like configuration can save months of bickering.
  • spamizbad 6y ago
    I think this gets solved easily by using autoformatting tools and use them as pre-commit hooks or an informal agreement among the devs to have their dev tools run it on save or whatever.
• illustriousbear 6y ago
  Another low effort blog post that Hackernews readers have upvoted because it says obvious things that they agree with. Quality on blog posts and articles is taking a bit of a dip lately.
  • hvasilev 6y ago
    I agree. There are maybe 1-2 articles a day that are really worth reading here. I skim the rest.
  • slx26 6y ago
    People with experience are acknowledging this has value for newbies. That you already learned the lessons doesn't mean they aren't valuable to others. Sure, not the most exciting and creative piece of writing we have seen this year, but there's no need to be so dismissive either, we shouldn't let our own experience blind us.
  • tgv 6y ago
    It's just a list, no arguments, so that's not high quality, indeed. But the author speaks from experience, and it resonates with experiences from others here, mine included (although I'm using a nosql db for recent projects). It offers a starting point for some discussion and elaboration, so it's fine by me.
  • heresie-dabord 6y ago
    I disagree, this is healthy exchange. Programmers -- and their employers -- want to discuss what works and what doesn't in the crazy world of software development. Although this might not be a moment of reflection for you, there are software projects big and small happening all over the world, every day. A large proportion of them fail. Or don't fail completely as long as we learn something.
• snidane 6y ago
  > So called "best practices" are contextual and not broadly applicable. Blindly following them makes you an idiot. Very true. "Best practice" are most often just "common practices" - how we've done things here forever. That's great for standardization. It gets annoying when each team member does things their own way. But it's a stretch to call them best. The research into what is truly best, A/B tests of various methods, or building prototypes of new experimental frameworks is rarely scheduled in sprint plans. It's actually some crazy programmers who try out these experiments in their off time based on their experience with the actual problems, which leads to truly innovative things.
• akdas 6y ago
  > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. This has been my gut feeling for a long time, and in the last year, I finally took the time to write down my thoughts on the topic. Every week since February 2020, I wrote about some aspect of interviewing that could be improved [0], and I now feel confident there are actionable improvements to be made. Individually, we as interviewers can shift our mindset towards looking for strengths instead of weaknesses, accommodate different backgrounds, acknowledge the best developers are not the best interviewers (both as candidates and interviewers), and put in the extra effort to hone our interview skills. At an organizational level, I'm working on training material that I hope to promote within companies that are interested in improving their hiring process. Interviewing is thoroughly broken. But I have some ideas to make it better. [0] https://hiringfor.tech/archive.html https://hiringfor.tech/archive.html
  • asiando 6y ago
    The blog you mentioned has interesting articles. Do you have by chance also something similar but for the person on the other side of the desk? I’d like to sharpen my skills to be interviewed. I’m the developer who never has questions at the end.
    • Falkon1313 6y ago
      Always have questions - interviewing is a two-way street. You want to find out what they value, (what's their quality vs speed tradeoff? etc.), and what sort of things they have problems with (possibly something you could solve to really stand out?) Those are just the most basic and obvious ones. Maybe hard to think of on the spot, but you can think of others in advance and have them ready.
    • akdas 6y ago
      Thanks! That newsletter does have articles geared toward candidates as well, though a lot fewer. The topic of what to ask at the end is one I floated around, but I didn't find it to be a priority. In an ideal world, the questions at the end wouldn't be part of the evaluation anyway, so it should be a time for you to ask whatever you want. Unfortunately, I'm sure interviewers do judge based on those questions, so if anyone has insight into what "good" questions are, I'd love to know.
• dvtrn 6y ago
  Inspired by this post and Something I’ve slowly been coming around to: “Silos probably aren’t the problem. Silos with no conveyor belts between them probably are”
• throw14082020 6y ago
  At my company, we have a stand up with Between 15-20 people. Personally, i think everyone is kind of disengaged, and nobody really knows each other. Everything is done remotely obviously because of COVID. The founder believes in working together in the office, so remote working may not be embraced. So I would add what I learnt to the list: Keep stand ups small, between people who are actually working together on a specific problem/ product.
• karmasimida 6y ago
  Very insightful post. Best for this month maybe :) Some of which I like most: > Clever code isn't usually good code. Clarity trumps all other concerns > Bad code can be written in any paradigm > So called "best practices" are contextual and not broadly applicable. Blindly following them makes you an idiot > Designing scalable systems when you don't need to makes you a bad engineer > In general, RDBMS > NoSql > DRY is about avoiding a specific problem, not an end goal unto itself Overall, software engineering is NOT a solved domain, nor it needs to be. Best practices works best solving others' problem, but most likely, your problem is different, and you are different as well. Don't be scared to do things in the way that you think is not approved. Exploration is necessary, because unknown is inevitable. Stay fluid and vigilant, be skeptical yet adaptive.
• cercatrova 6y ago
  After reading these, I am wondering how anyone could've thought differently, as I agree with them all and it seems to me that to disagree with any of them doesn't seem to be reasonable. For example, typed languages are of course better than untyped ones, especially for large codebases with multiple levels of experience of the people who write them. In other words, these seem to be exactly the opinions that the majority of HNers would agree with, and it is one of the least controversial lists I've ever seen.
  • sa46 6y ago
    I agree with most of the list. It's a good distillation of software development principles. In the spirit of HN, here's what I disagree with: > Designing scalable systems when you don't need to makes you a bad engineer. Creating overly scalable solutions is useful for learning, especially early on. I've done this. > Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers. This is true in almost every human endeavour. It's not a useful opinion. Most decisions don't matter that much so adding data is a waste of time. > Code coverage has absolutely nothing to do with code quality I don't buy there's no correlation between code coverage and code quality. I'd much rather take code with >80% coverage than 0 coverage. My revised take is that the value of code coverage rapidly diminishes past 80% (maybe log scale-ish). I also think code coverage metrics are not especially useful outside of library code. > 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. Google tried getting rid of managers. It didn't work. Establishing lines of communications in large orgs is hard.
• mastrsushi 6y ago
  >Java isn't that terrible of a language. Someone had to say it. So sick of the fashionable hatred towards what actually makes things work.
• l0b0 6y ago
  > People who stress over code style, linting rules, or other minutia are insane weirdos I suspect this has to do with a combination of personal preference and never having worked with a reliable (in terms of just never changing the semantics) code formatter like Black. Sure, I don't agree with every single thing Black does, but it's still infinitely better than trying to enforce code style manually. And don't get me started about those who just don't want a code style enforced - the diffs end up a serious mess, and forget dealing with merge conflicts in a reasonable time.
  • smolder 6y ago
    Notice the author said people who stress over code style. Using a code formatter and forgetting about it is a great way to not stress about it. Fighting with your tools or your team to get things a certain way is where the folly is, I think, and that's how I interpreted their comment.
  • asiando 6y ago
    I’m the kinda of guy who has a strict linter and will force you to rewrite every PR you submit, but the result is that most of the time better style means you see the problems better and very often the diff (or additional code) is halved. I could merge that PR as is because it seems to work, but I don’t because I don’t want to deal with those hidden bugs in 10 days on production.
  • psyc 6y ago
    Yeah this is the one point I don’t get. I’m not sure what “stress over it” means here. I don’t know why I’d stress over it. I’d stress over having indeterminate and mixed styles. Strict style greatly lowers mental overhead, particularly on a team (esp if larger) where one person needs to jump in and work on code others wrote.
  • toast0 6y ago
    I think this is a nuanced point. Enforcing code style manually probably means not enforcing code style (at best, selective enforcement). But, I've yet to see a good tool that only enforces format on new/changed lines; and a reformat en masse is asking for trouble. However, the arguments about a consistent style giving you benefits seems to fall flat when you've got dependencies that don't follow your style. If you're in go, and everyone uses gofmt, and always has, I guess that solves that. But you probably still have some code that's not in go (the OS you run on, at least), and that's probably not consistent. And if you're not in Go, you may have a different required style than your libraries and your language environment and nothing is consistent anyway; so why enforce anything beyond best effort blend in with the surrounding context?
• lrossi 6y ago
  > People who stress over code style, linting rules, or other minutia are insane weirdos Cannot agree with this one. For example, different indent size can be misleading and has introduced many bugs that are hard to notice during review. Apple had a security issue because of this.
• cryptica 6y ago
  It sounds like were I was around my 5th year of coding. After 15 years though I changed my mind again on certain things. > Typed languages are better when you're working on a team of people with various experience levels I've changed my mind back and forth multiple times about statically versus dynamically typed languages and after 10 years I settled on dynamically typed languages as superior in almost all cases. The main case where statically typed is better is if most people on your team are juniors and you are doomed to produce poor quality code so in this case you might as well 'label the spaghetti'... I can say with almost 100% confidence that sticking to dynamically typed languages leads to worse quality in the long run. It has to do with loss of separation of concerns and subtleties of human psychology (gives false confidence, leading to neglect, encourages over-engineered interfaces which creates tight coupling between components and thus ossifies design mistakes and makes them less interchangeable and interoperable with other systems). > Software architecture probably matters more than anything else. This is the most important thing. 100% true. Glad the author seems to really get this. Some people don't figure this out after 20 years. > Designing scalable systems when you don't need to makes you a bad engineer. I disagree about this point. Writing scalable code can be elegant and fast development wise and performance wise. It just requires more careful design to get right. A bad or even 'mid level' engineer will over-engineer it; that's the real problem. A bigger problem is when engineers create too many unnecessary abstractions and that doesn't scale in any way. In many cases, scalability requires very few abstractions in order to work. It requires very elegant code.
  • cryptica 6y ago
    >> I can say with almost 100% confidence that sticking to dynamically typed languages leads to worse quality in the long run. I meant to say 'statically typed languages' here but the popular narrative is so strong it must have seeped into my subconscious.
• Fire-Dragon-DoL 6y ago
  > Pencil and paper are the best programming tools and vastly under used This should probably rephrased to "taking notes", if I understand what it's suggesting
  • looshch 6y ago
    I think the author meant writing ideas down and visualizing them with pencil so you can quickly amend what you already have drawn along with freeing your cognitive capacity
• eecc 6y ago
  One thing that bothers me and is only tangentially mentioned is code formatting. I don’t have particular favorites but I do appreciate consistency but most importantly: when introducing or changing a formatting rule apply it to all the project in 1 commit. Never, ever dare to apply it “as-you-go” when implementing changes and touching existing files. Makes reviewing a nightmare
• hamza__nouali 6y ago
  > So called "best practices" are contextual and not broadly applicable. Blindly following them makes you an idiot Following best practices will make it impossible to think outside the box (limits the creativity).
• royosherove 6y ago
  I'll add after 20+ years: - Being able to communicate ideas > Being a great technical developer - For every great developer that's an asshole, you can find a great developer that won't be an asshole. Don't keep assholes. Google the "no asshole rule". - Making the team feel safe to discuss stuff they don't know freely and ask questions that might seem stupid in other teams makes for a great team that's not afraid to challenge assumptions and break through with new skills. - TDD is a skill just like refactoring. Learn when it makes sense. - 80% of architects in enterprise don't have the skills needed from them. including the things stated above. - Learning the Theory of Constraints and applying it to find bottlenecks in the process, pipelines and structures of your teams/projects is one of the most useful things you can apply to become more productive. - Learning what to measure and what not to measure, lagging vs leading indicators can help you communicate to management about what changes truly need to happen to make your team work more effectively. - Whiteboards (and remotely, miro boards) are very effective and can be used for easily 50% of meetings. But aren't.
  • dxdm 6y ago
    > Whiteboards (and remotely, miro boards) are very effective and can be used for easily 50% of meetings. But aren't. I agree that it's great to have a visualization aid, especially in remote meetings. But in my experience, for the needs of most meetings, Miro boards are a cumbersome, over-featured sink of time and effort. Then they invite you to leave them standing as sole documentation of the details of a meeting's outcome, which they're not very good at. Use them wisely!
• koonsolo 6y ago
  Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity trumps all other concerns. My measurement is "simple and clean" code. Is it simple and clean? No? make it so! > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough. One last thing I like to remind myself: "Good enough is always good enough". Sometimes "good enough" has a low bar, sometimes high. You always need to reach it, but never want to go too far above it.
  • deleted 6y ago
    [deleted]
  • jka 6y ago
    Your mention of simple and clean code makes me think of the excellent talk "Transforming Code into Beautiful, Idiomatic Python". Although it relates to Python programming, if the ideas and principles (and thoughtfulness and pace) from it could be applied to much more written code, then (I think) we as an industry and all our users would be in a better place. [1] - https://www.youtube.com/watch?v=OSGv2VnC0go https://www.youtube.com/watch?v=OSGv2VnC0go
    • Chris_Newton 6y ago
      Possibly worth noting that the presentation there is a few years old now and appears to be using Python 2 for the examples, so some of the code wouldn’t be exactly the same in Python 3 even if the ideas still make sense. With that caveat, watching almost anything that Raymond Hettinger presents is positively correlated with improving programmer skill.
  • radicalbyte 6y ago
    I'm also at 20 years, and he has hit the nail dead on. I can add a few things: * Operational considerations dominate language choice. * Architecture too. * Politics, leverage and all that MBA crap dominate all of that. * Language zealots are net negative idiots and need taking outside and shooting. * Actually apply that to all zealots. * The root cause of the above is often insecurity; and it can be coached / cultured away. * If your lead/management doesn't get that then they're in the wrong job, get out. * If you see shady consultant types and "thought leaders" talking about something, then it's just the latest bullshitchain. * If you see a junior developer say "this is easy", then let them learn the hard way, but manage expectations. * If you see Senior level engineers constantly say "this is easy" when the problem isn't clear, then run for the hills * The 10x engineer is only true in special cases and does not generalise. * That ^ is why you need to work together so everyone is doing their 10x task. * Incompetent engineers and bad actors can act as negative 10x engineers. * The vast majority of people on the outside of the team (consultant types) are worse than the above. With interviewing I have decent results just having an open form conversation, looking first for personality and drive and getting an idea of their technical knowledge by seeing how deep they can go (or if they even can go deep into a subject). References from someone competent dominate, mind.
• stickshift 6y ago
  Was 'scum master' intended?
• ehnto 6y ago
  > 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I agree with the majority of the article, but I feel this is a shallow thought. It really depends on the context as much as the PM. In an agency environment, I love PMs. Lots of the things they do on the developers behalf just aren't in my job description. If I had to do them, I'd get half as much code written. I think PMs also get a bad wrap, because they are essentially the interface between a developer and the client. When the client is bad the PM can help shield the team from much of it, but ultimately the developers are going to feel the worst of a client through the PM no matter what.
  • Falkon1313 6y ago
    I agree with you 100%. Where I work now, all of our PMs are subject matter experts. Some of our software relates to chemicals and our PM for that project is a former research chemist, for example. Their input is invaluable, since they know both the problem domain and the software development domain. In a former job, at an agency, we didn't have that but still the PMs were the ones who dealt with cranky customers and sat through long meetings with sales etc. Also, good PMs will tell you when something doesn't matter so you don't waste time on it. In either case, they handle all the difficult stuff and get us the info we need to do our jobs well. If I was to go back to freelancing or consulting, I'd hire a manager right away to handle all that stuff so I don't have to.
• ClayShentrup 6y ago
  > YAGNI, SOLID, DRY. In that order. Hell yes.
• skohan 6y ago
  Very good list in general, but I would disagree with one point: > Software architecture probably matters more than anything else The devil is in the details here, but the more I program, the less I feel that "software architecture", at least as it is often discussed, is actually not important and often actively harmful. The architecture driven approach takes the assumption that the "correct" shape of a program should fit into a pre-defined abstraction, like MVP, MVVM (or god forbid atrocities like VIPER) etc which has been delivered to us on a golden tablet, and our job as programers is to figure out how to map our problem onto that structure. In my experience, the better approach is almost always to identify your inputs and desired outputs, and to build up abstractions as needed, on a "just-in-time" basis. The other approach almost always leads to unnecessary complexity, and fighting with abstractions. The author also mentions SOLID - like architecture patterns, I'm always a bit suspect of true-isms about what makes good software, especially when they come in the form of acronyms. I generally agree that the principals in SOLID are sensible considerations to keep in mind when making software, but for instance is the Liskov Substitution Principal really one of the five most important principals for software design, or is it in there because they needed something starting with "L"? After 10 years of programming, the biggest takeaway for me has been that the function of a program (correctness, performance) is degrees of magnitude more important than its form. "Code quality" is important to the extent that it helps you get to a better functioning program (which can be quite a bit) but that's where its utility ends. Obsessing over design patterns and chasing acronyms is great if you want to spend most of your time debating with colleages about how the source code should look, but the benefits are just not reality-based most of the time.
  • AnimalMuppet 6y ago
    So you don't think architecture matters that much, but you've felt the pain of having one that doesn't fit forced on you? That seems... kind of unaware of you. Just-in-time architecture is a perfectly valid approach to developing an architecture. The point is to develop one that is a good match to the problem. If you don't have that, you suffer - and that's the point of what you quoted.
    • skohan 6y ago
• dvfjsdhgfv 6y ago
  > 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. That's my experience, too, but only in short term. In the long term, they can make a difference (either way).
• p0nce 6y ago
  Interesting take, that order on: YAGNI, SOLID, DRY.
• eecks 6y ago
  I seem to be the only one confused by the list. Could someone clarify? When the author says "Java isn't that terrible of a language." in the "Things I've changed my mind on" are they saying they used to think Java was not a terrible language and now think the opposite? (i.e. current opinion is that Java is a terrible language.)
  • deleted 6y ago
    [deleted]
  • mkl 6y ago
    He introduces that list with "Things I now believe, which past me would've squabbled with". It seems pretty clear.
    • eecks 6y ago
      Ah thanks, I must have skipped over that line.
• majkinetor 6y ago
  I would add just one - Automation of everything is what you need in 99% of cases. There are almost 0 cases when you automate something and it turns out that you could have done it more efficiently manually (even in that case, learning experience makes it usually worth it, while such manual work provides almost 0 XP).
• layoutIfNeeded 6y ago
  >Java isn't that terrible of a language. You’re onto something, but not yet enlightened. The next level will be realizing that languages don’t matter at all.
• nalekberov 6y ago
  > 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I can't agree enough.
• swyx 6y ago
  I love it when engineers admit changed opinions! here's a recent thread from charity majors: https://twitter.com/mipsytipsy/status/1349262816239263747?s=20 https://twitter.com/mipsytipsy/status/1349262816239263747?s=... and from me: https://twitter.com/swyx/status/1349279194446876673?s=20 https://twitter.com/swyx/status/1349279194446876673?s=20 basically (things I no longer strongly believe or in fact did a full 180 on) - "Time travel debugging is only for showing off in demos" - "HSL is better than RGB because you can control hue, saturation and lightness as independent variables." - "We should move all errors to compile time, the earlier we catch them the more productive we are" - "React/Preact is the best paradigm to code websites." - "Monorepos trade off contributor/bug reporter experience for maintainer convenience." - "If you can support dark mode you might as well support infinite themes"
• alexchamberlain 6y ago
  s/best practice/good practice/g It shows an appreciation that there may be a better practice in the reader's situation and that the writer doesn't think they know everything forevermore.
• Tade0 6y ago
  So called "best practices" are contextual and not broadly applicable. Blindly following them makes you an idiot I've come to associate the expression "best practices" with "a set of unwritten/badly documented rules which accumulated over the years and which we apply manually and thus inconsistently, even though we could automate this at least in part". Sometimes I wonder what would happen if my "best practice evangelists" from various projects I've been in met.
• thequux 6y ago
  > Clever code isn't usually good code. Clarity trumps all other concerns. Generally this is true, but with the caveat that what actually matters is 90th percentile (or maybe even 99th percentile) complexity. If you have a choice between spreading low-grade complexity across the codebase or having one module that is nearly incomprehensible but that provides an abstraction that makes the rest of the code very simple, the latter is almost always to be preferred. Once you've distilled out the evil into one place and gotten it working reliably, chances are you're never going to need to touch it again, and if you do need to, at least you only need to deal with it in one place.
  • silentsea90 6y ago
    Interesting problem. I'm not convinced but don't have strong opinions on this. I feel nobody wants to touch the high grade complexity code so it would rot. Ultimately, reading code dominates writing it, so having low grade complexity spread around seems better as the bar for reading is lower
  • skohan 6y ago
    If I understand what you're talking about, I tend to disagree - I've had a bad experience in general with "pure abstraction" layers in projects. It sometimes seems like a good idea to have this "magic" component which automates everything and takes care of all the hard stuff, but in practice it creates a whole host of problems. For instance, maybe it works at first, and then your requirements change in a way that doesn't fit the abstraction. Now you can't make local changes, you've got to change this super complicated abstraction layer, and suddenly it requires changes all over the place in completely unrelated components, because you had to add an argument to `super_general_magic_function_that_is_used_everywhere()`. Also things like this tend to make code super hard to trace. Instead of stepping through your functions, now all your tasks are running through some generic scheduler or something, which is there because somebody had the idea that if you ever need to run your code on a Hadoop cluster this would help, even though your code has only ever been run on a Raspberry Pi.
    • erikpukinskis 6y ago
• eeZah7Ux 6y ago
  > Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers This is the most important part. Most companies don't have a mindset of doing research and analysis before taking a decision. No training is provided around this. Most "engineers" want to play with shiny toys without being held accountable for any decision.
• laurentdc 6y ago
  > 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. True especially when you get a project manager with no CS/IT background at all (pretty common in consulting for some reason). Then the project is really doomed from minute one.
• raverbashing 6y ago
  > People who stress over code style, linting rules, or other minutia are insane weirdos > Code coverage has absolutely nothing to do with code quality > TDD purists are just the worst. Their frail little minds can't process the existence of different workflows. Amen! I have skipped the Monolith one because I'm not "that sold" onto it, but I'm certainly not on the side of "put your monolith on a cheese grater and leave with thousands of services"
• KaoruAoiShiho 6y ago
  Fantastic post, think he'll come around on this one > People who stress over code style, linting rules, or other minutia are insane weirdos
• shoulderfake 6y ago
  "People who stress over code style, linting rules, or other minutia are insane weirdos" -- best one hahaha
• mbar84 6y ago
  > Typed languages are better when you're working on a team of people with various experience levels I would extend this to say that a test suite, static analysis, linting, code formatting and a ci setup are more and more important, the bigger your team is.
  • skohan 6y ago
    I would also add that, when a project extends over a long period of time, your past self can also be the team member who these tools help to keep in alignment with.
• user5994461 6y ago
  >>> Typed languages are better when you're working on a team of people with various experience levels I picked up the opposite qualm after working in a multi million line codebase in python, that goes back almost 2 decades in a large bank. Dynamically typed languages actually work, at all scale. Statically typed languages are good for simple types (int/string) but they're catastrophic for complex types (dict, map, database tables, enum, nullable/optional). The guarantee it gives you on simple code is great but the convolution it forces you to go through for more complex data is equally horrific.
  • skohan 6y ago
    I think it depends on the type system. After working with languages with good inference, explicit nullability, and algebraic types, it feels extremely tedious to go back to un-typed or duck-typed languages. With a language like python, you spend a tiny bit less time typing out types in the source code, but that savings is totally eclipsed by the extra time you need to spend reading through documentation and source files to make up for the information which is missing from function signatures, and the time you spend chasing down bugs at runtime.
  • hyperpallium2 6y ago
    The big benefits are types-as-documentation and automated tooling.
  • IshKebab 6y ago
    I strongly disagree. Static types have so many benefits they easily outweigh the only downside (you have to actually write them). I'm sure it's possible to make large dynamically typed codebases work with a lot of effort and a ridiculous amount of testing but it would clearly be easier with static types. There's a reason Typescript is so popular and pretty much every dynamically typed language has some effort to add type hints (including Python!). There's also a reason why you see so many blog posts about large dynamically typed code bases being converted to statically typed languages or having type hints added (e.g. Dropbox) but I don't think I've seen a single large company go the other way, because that would be crazy.
• darkerside 6y ago
  > TDD purists are just the worst. Their frail little minds can't process the existence of different workflows I'm not one, but my money is on this one changing, at least in tone. It's deliciously ironic as currently written.
  • burnthrow 6y ago
    Maybe you've never experienced the anguish of having to pair program with a TDD purist. I honestly wonder how these people tie their shoes without performing a few deliberate face-plants first "just to make sure."
• seba_dos1 6y ago
  Is it just me or do those things seem very... obvious? I mean - almost every single one of them makes me question how can you even have a differing opinion that wouldn't immediately make you seem like you're mindlessly repeating hype phrases.
  • clintonb 6y ago
    Common sense isn’t common, and sometimes it helps to write down the obvious. Obviously planes should only land with the gear down, yet not all planes have. Hence the use of checklists stating the obvious: lower the gear.
    • seba_dos1 6y ago
      Is lowering the gear something you have changed your mind on though? ;)
      • clintonb 6y ago
        Lowering gear is a strong belief tightly held. I don’t think I’ll change my mind on that. :)
• donaldihunter 6y ago
  First two bullets could do without the qualification, IMHO. “keeping an eye on the newbies” is just condescending. My take: * Typed languages are generally better. * Standups are actually useful. * Process is helpful, when not used as a straitjacket.
• satya71 6y ago
  Solid list. I'll disagree this. > People who stress over code style, linting rules, or other minutia are insane weirdos We use Black for Python, Prettier/Standard for Typescript. Code is readable across developers and there is no question about how it should be formatted. Make this easier: > Clever code isn't usually good code. Clarity trumps all other concerns.
  • 3836293648 6y ago
    I read it as people who stress over what the style should be, not people who think there should be a style. I have my opinions on what should be in .clang-format, but that's debatable and beside the point. HAVING a .clang-format and using it is a different question and something very important (obviously you should use go-fmt or rustfmt or whatever is applicable, but clang-format covers most of it)
    • satya71 6y ago
      Hmm. Good point
• hnysahglie 6y ago
  Best one: "TDD purists are just the worst. Their frail little minds can't process the existence of different workflows."
  • pcmoney 6y ago
    They can they just typically don’t want to go roll about the muck once they have achieved full galaxy brain. Mostly trolling but I do think following XP dogmatically early in my career gave me an accelerated appreciation and understanding for a lot of the other bullet points. I don’t always TDD now but I can typically tell if code was written via TDD or not just by reading it.
• jameshart 6y ago
  It’s interesting, I think, how many people this resonates with. Why do people enter the software business with such strong beliefs about topics like this that after a few years they realize they were wrong?
  • AnimalMuppet 6y ago
    Because universities have teachers that haven't spent six years in industry to learn these things, and they pass on their unsupported-by-real-world-experience ideas to their students.
• submeta 6y ago
  > People who stress over code style, linting rules, or other minutia are insane weirdos He seem to have not seen messed up code written and changed by a dozen programmers over the course of years with various notions about indenting, placing parentheses and comments and whatnot. I‘ve seen code with tabs and spaces mixed, wrongly indented code where following the logic is hard, code with no comments at all or code with more comments than code. Don‘t give any guidelines and you‘ll end up with a mess.
  • omosubi 6y ago
    As far as I can tell he isn't arguing for not giving any guidelines, but rather that arguing over them is pointless. choose a set and be done with it.
  • Joeboy 6y ago
    We don't stress much about code style etc, because we have a pre-commit hook that complains if you don't follow (most of) pep8. It's extremely unstressful, and makes our code nicer. I guess it could be different in languages where style is more of a matter of personal opinion.
  • conradfr 6y ago
    At my last workplace someone made a change that was preventing you to commit if your imports ("use") where not sorted alphabetically. They are so irrelevant that the IDE (PhpStorm) hide them by default. It used to make me so mad.
• duosonic 6y ago
  I realize this may get lost in the comments and also that I am partially just venting from a bad week at work with a particularly stressful dev, but... Is anyone else just sick of developers with hyper-condescending tones like this?
• dalu 6y ago
  That guy is a fruitcake. Pencil and paper are the best tools? I don't need other tools than my fingers, a keyboard and the IDE and sometimes a search engine they delivers relevant results. That guy is not a developer and if he is he's not talented. I would never hire someone like him. Pure waste of time reading this.
  • shepherdjerred 6y ago
    I can't tell if you're serious. Anyway, if you're not using a pen and paper you're either really smart or you're solving easy problems.
• likeabbas 6y ago
  > 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I'd extend this point from "project managers" to any manager
• ameixaseca 6y ago
  About the first point, remember you might have to maintain or refactor code you wrote 5-10 years ago. You will have a different experience level from your past self and likely won't remember why you did a number of architectural decisions. IOW: typed languages are better, period.
• amai 6y ago
  I haven't done 100 coding interviews. But here is a suggestion to fix the interviews: Let the candidate bring their own code! First this gives you a unique inside in the programming style the candidate prefers. Second the candidate knows the code very well and is probably more relaxed when he needs to answer your questions about the code (given that she/he didn't copy-paste the code from somewhere). It is similar to designers showing a portfolio of their work to a potential employer. So if this works for designers, why not for programmers also? It is called "The Art of Computer Programming" for a reason. ;-)
  • bena 6y ago
    The problem with that is that we can't be sure that it is their code. And let's be honest, it doesn't really work for designers either. Because the problems of hiring programmers isn't unique to programmers. Hiring gets harder the more you need out of your workers. Take any reasonably skilled position, hiring is incredibly difficult because it's hard to evaluate a person's skill in the blind. Hell, it can be difficult even when we do have ways to evaluate skill. Take any major sports league. The draft is essentially teams hiring players. And they've spent the entire year evaluating hundreds, if not thousands of players to find out which ones are good enough to be hired. They have games to look at, stats to pore over, people to talk to about these players. And they get it wrong often. Finding good people is a hard problem to solve.
    • hycaria 6y ago
      I am a veterinarian and recruiting is way more straightforward. You’re not going to test the person on the spot. It’s way more about personality fit, what you like/dislike to do, and where you see yourself a few years later down the road. And then a real paid tryout. Also I just changed jobs and was able to write code quickly because they were recruiting with tasks in mind for me. Sometimes it feels like the position is just opened to have more velocity on the sprints.
      • bena 6y ago
        Veterinarians have boards and licenses, right? I can't hang a shingle as a vet on a whim. That's a very clear filter. All the vetting of whether or not someone can perform the job is done before they even get to you. However, anyone can call themselves a programmer and apply to programming jobs and there's no way to tell if they're capable or not until they're at it. And even previous job experience isn't a strong signal of competence. I've inherited code bases from people who left for other programming jobs where the code they left behind was just a mess inside.
• hallway_monitor 6y ago
  Interviewing is mentioned. I'm currently doing a lot of that and I agree it's challenging to assess engineering skill. We currently use a fairly simple coding challenge that shouldn't be a problem for anyone with some experience. We basically pair program with them for an hour or 90 minutes (remotely for now) to see how they work through problems and write code. It has been pretty successful so far.
• Geminidog 6y ago
  I disagree with software architecture. There's not enough theory and science in organizing code and understanding complexity. Most of what goes on here is just guessing. If you created "good architecture" it only means future requirements happened to fit your design, aka you made a good guess. Rarely does anyone design anything that is efficient in the present and adaptable to any possible future simply because there's no science and theory on how to design such a thing. There's some rules of thumb but even following these rules of thumbs people end up with technical debt most of the time anyway. It always happens, if a project lives long enough, more and more "design mistakes" made at project inception become evident. I have personally found tacit programming to be the solution for this but because there's no theory I can't explain to you definitely why tacit programming is the best way to deal with tech debt of the structural nature.
  • itsArtur 6y ago
    > Software architecture probably matters more than anything else. A shitty implementation of a good abstraction causes no net harm to the code base. A bad abstraction or missing layer causes everything to rot. That's fair, but shouldn't we strive to make the best possible guesses in the absence of said theory and science?
• hermitcrab 6y ago
  >People who stress over code style, linting rules, or other minutia are insane weirdos Counterpoint: People whose source is sloppy (inconsistent naming, indentation, brace placement etc) are almost certainly bad programmers.
  • bena 6y ago
    True. But I don't think he's talking about that. I don't particularly care if you prefer tabs over spaces, or if you do brace on the line or on the next line, or one of the many other trivial details that don't affect the code quality. I do care that you have a preference though. I do care that you're consistent in applying that preference and have reasons where you break with that preference. I have my own preferences, but if I were in a shop where the style guide was to do the opposite of them, I'd do the opposite of them because it's not worth fighting over. It's more important for the code to be uniformly styled so it's easier to read and maintain rather than it to be styled in a way I prefer.
    • hermitcrab 6y ago
      Yes, it is the inconsistency and lack of attention to detail that is the giveaway, rather than the use any particular convention. Unless they don't vertically align their braces, then they are clearly some sort of monster. ;0)
• mshenfield 6y ago
  This list is self-consciously blunt/rude (correlating programming practices with intelligence and sanity) and unaccountable ("who knows what I'll believe in a few more years"). It's an annoying combination. I imagine many reader will haughtily deploy these commandments against their colleagues.
• jll29 6y ago
  I agree with most of your assessments. > Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers This is indeed so, most people are developers/programmers rather than software engineers. As a discipline, writing/crafting code still lacks the systematic approach of other engineering disciplines. If I ask for a house to be built for me, people give me a plan as well as cost & time estimates, as part of a pretty standardized process. For sofware, there is much of a zig-zag route towards a foggy end goal in many projects. That's why I'm working on a methodology to make things more systematic (there are of course many people working on methodology, some heavy like UML, some rather light/"agile", my focus is on methodology for data-intensive systems - systems that require machine learning components, which imposes a rather special list of process requirements on the project, for which nobody appears to have written up detailed guidelines/best practices, so that's ongoing). > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. I've interviewed a few hundred people in recent years, and been interviewed a few times myself. I agree most people use a broken process. My idea for making it better is: (a) cover a range of areas: motivation/goals - interpersonal - project experience - management - algorithms & data structures - coding practice. No silly logical riddles, but examples that are common in the daily life. So in case they really have been doing what their CV says, they should not need to have to practice for any of it.
• stephen82 6y ago
  > Monoliths are pretty good in most circumstances This 1M %! I have seen a company being approached by an agency to design and implement them an e-commerce website that consisted of multiple web services and when I was asked for feedback, I said "start small; go with WooCommerce and when you hit it big, give me a call." They are making 500K euros selling goods while being hosted on a shared hosting with a WordPress / WooCommerce website and the server spikes at 25% the most when traffic hit the website lol! I will paraphrase the well-known "optimization / evil" and say: Over-engineer your infrastructure before go live will definitely lead you to failure, let alone bankruptcy.
• Hrun0 6y ago
  > Designing scalable systems when you don't need to makes you a bad engineer. Oh no. He is 100% correct. Also I am a bad engineer.
• ricc 6y ago
  > 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I don't know how 6 years of experience in the industry can confirm this but nonetheless, I do agree that indeed there are software engineering teams that don't need, perhaps even impeded by, PMs but I think they are fewer than average. I would agree if the numbers are reversed, i.e. 7-10% PMs are not needed. Many developers love to hate on PMs but I think most teams overestimate themselves and think that they're mature and self-managing enough to not need a PM. It can be true that the individuals in the team are self-managing on their own but it's different when it's scaled to a whole team. For example, it's difficult to finalize a decision when most experienced and opinionated team members have differing opinions. A PM serving as an arbiter can help resolve this deadlock. (Yes, there are strategies out there on how to make decisions w/o an arbiter but then, how do they decide which strategy to use?)
• RickJWagner 6y ago
  "Clever code isn't usually good code. Clarity trumps all other concerns." Nail, meet hammer. Mic drop. True dat. Word!
• KoenDG 6y ago
  Always found the concept of "code coverage" to be a weird phrasing of what's actually happening. The whole point is to answer the question: do your unit tests walk all possible paths in your code? Now, the whole point of unit tests is to verify code behavior. See if it remains consistent if you change something somewhere, that kind of stuff. Don't want the new hire to make a well-intended change that ends up breaking things. This is why unit-tests exist. Amongst other things. One may well write tests such that all possible code paths are checked... doesn't mean the actual code is performant or written in a clear manner, or written in a maintainable manner, etc... I guess a better term would be "behavior coverage" or something?
• montana399 6y ago
  https://www.tb42trk.com/5MX46D/6RGC42/ https://www.tb42trk.com/5MX46D/6RGC42/