7 ms·
My best bit of advice for any programmer at any level: "Don't make stuff more complicated than it has to be!" Software is complicated. Large, feature rich soft
by wolframhempel 3y ago
My best bit of advice for any programmer at any level: "Don't make stuff more complicated than it has to be!"
Software is complicated. Large, feature rich software is even more complicated. That's hard enough to manage as it is. The last thing you want to do is to throw a million of abstraction layers, frameworks, libraries, precompilers, transpilers, build steps, validation hooks, style checkers etc. into the mix. Each of them makes your project more complex by a certain factor. And not only do they add up - they multiply!
Now, that doesn't mean that you need to built everything bare bones without the help of any third party software - just make sensible choices. Unfortunately, developers are way too prone to add another shiny thing to the mix.
So here's how you decide if you really need something:
At first: You don't - continue as is.
Then: If the problem persists and the suggested solution keeps coming up, still refuse, but investigate the solution.
At last: If the problem persists, the solution seems well suited to address it and it keeps coming up - accept that you have the problem and adopt the solution.
- loloquwowndueo 3y agoI think an automatic code formatted actually makes one’s job easier, not more complicated.
- max_sendfeld 3y agoAbsolutely! I'm grateful that I don't have to worry about code formatting any more. But I remember in one of my earliest job the company used style checkers as a pre-commit hook that rejected your commit if they found trailing whitespace. That was before code formatting was part of your IDE. (Especially for us front end devs who used Notepad++ rather than an IDE at the time). And notepad++ had no easy way of showing trailing whitespace. So every commit was a dance of commit -> read rejection log -> remove trailing whitespace -> commit again.
- EZ-E 3y agoI have memories at my post grad school where any deviations from the expected code source formatting led to a -1 on the mark. On the first few projects it was not rare to see students getting marks well into two or three digits negatives.
- bluGill 3y agoThings that don't matter much. A nice consistent style is good to have, but it isn't something worth worrying about that much.
- hudell 3y agoI once worked on a project that would not even compile if a function had a param without a comment explaining the purpose of that param written with a specific format. Every comment was validated on compile time, you couldn't even comment code just to test something. Life was hell.
- yakshaving_jgt 3y agoWhat's stopping you from configuring your editor to automatically strip trailing whitespace on save?
- max_sendfeld 3y agoMostly the fact that this was 15 years ago :-)
- skirmish 3y agoCode reviewers that made me type in trailing whitespace that editor stripped: "this change is on lines you are not modifying". Still makes my blood boil many years later.
- mlinhares 3y agoThat completely removes a whole slew of useless comments when people are reviewing code, it's such an amazing win, every single language should have it's styleguide published and a tool that forces it without any options.
- rTX5CMRXIfFG 3y agoThe key to style guides is to not have so many rules. Agree on the number of spacing and where to put braces. Past that, it’s obsessing on form over function, which you cannot control simply by virtue of having many people work together on the same codebase. You should worry more about how things are named, the number of abstractions used, and whether the code has any comments explaining the writer’s intent.
- kevindamm 3y agoYes, but, on the other hand having a detailed style guide does make for short and simple debate during code review.
- zaptheimpaler 3y agoThis is broadly what reasonable people believe, but there are crazy people who WILL obsess over form and nitpick your whitespaces or other trivial bullshit if given a chance. An authoritative style guide shuts down many such detours.
- thfuran 3y agoIt's not even just about obsessive nitpicking. There are people who, for example, prefer code with spaces around the parens for conditions and people who don't. If there's no enforced style guide and one from each camp end up touching the same code, you're likely to get a bunch of pointless noise in the diffs. Even if no one is going to hold up a diff arguing over it, it makes it harder to review changes.
- durumu 3y agoI think you can have as many rules as you want as long as there's something like black or rustfmt, just a script you run that auto-formats your code. You never have to worry about the rules because there is no configuration thus nothing to argue about. Sometimes your code gets formatted weird but who cares, just do your work.
- deleted 3y ago[deleted]
- EZ-E 3y agoDon't solve simple problems with complicated solutions
- andai 3y agoTrue. On the other hand, don't try to make things simpler than they are. https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory
- deely3 3y agoI believe we have another name for this theory: leaky abstraction.
- adverbly 3y agoTrue. On the other hand, the reason things are not simple is probably that your requirements are dumb. https://youtu.be/hhuaVsOAMFc?t=12 https://youtu.be/hhuaVsOAMFc?t=12
- andai 3y ago>The reason "simplify" is not the first step, is that it's possibly the most common mistake of a smart engineer to optimize something that should not exist.
- petesergeant 3y agoSeeing that that's attributed to Apocalypse 5, and Apocalypse 5 was >20 years ago makes me feel ... something not good.
- andai 3y agoI think this is explained by the fact that most business logic is dry, and most abstractions are interesting (until you get bored of them). So you wrap your actual code in fun code to make the job bearable.
- aleph_minus_one 3y ago> I think this is explained by the fact that most business logic is dry I don't think that business logic is dry per se. The problem in my opinion rather is that in other parts of the software project, there is much more openness with respect to - trying out new things in new ways - making the code more elegant - seeking abstractions - ... than in the business logic area. Believe me: for the kind of business logic that I see at work, I could immediately see ways in which the (non-trivial) business logic could be made much more elegant by using clever mathematical ideas, but suggesting such ideas to other colleagues or the bosses is like talking to a brick wall.
- deleted 3y ago[deleted]
- andai 3y agoIt seems to me that if you can see elegant simplifications (or really any significant improvements) but are unable to implement them, you are either positioned too low in the hierarchy, or in the wrong organization.
- Cthulhu_ 3y agoThis is the likely cause - most software development is dreadfully boring. But at some point in a developer's career, they will have touched the monolith and everything is full of stars, and instead of saying "I'll just hook you up with Magento", they're like "I will build you an event-driven microservices architecture in a custom made C# framework" and disappear for six months while they work late nights. (I wish I made it up. This was what a CTO at a previous project did. 30-odd people were waiting and churning on while he was unavailable because he had to indulge his own things. And once they were beyond the point of no return, both he and the manager that greenlit this project quit, but stayed on as independent contractors. I believe they were demoted or taken off the project and eventually gotten rid of when a new manager was found)
- brudgers 3y agoDebugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan
- corethree 3y agoNot an intelligent quotation. Hardness can be defined as how long it takes to accomplish a task. Following this definition everything can be debugged. It just takes twice as long. This definition isn't absolute and neither is the definition by Brian. The truth is much more complicated.
- Retric 3y agoYour premise is false, time to completion and difficulty are not equivalent. Believing such implies it’s more difficult to ride in an aircraft craft around the world than legitimately beat Magnus Carlsen in a rapid chess game. The reverse is frequently the case where running a marathon faster is more difficult than doing so slower.
- corethree 3y agoIt's as "false" as his premise of relating difficulty to intelligence. My point is the existence of an alternative statement that is equally and fuzzily true shows that this quote is not really that intelligent. Reread my post. I literally said neither definition is absolutely true.
- Retric 3y agoI understood what your post was saying, but they they aren’t fuzzy equivalents. The basic premise is just false. Further the quote wasn’t suggesting equivalency. Rather intelligence as one bound on debugging, which is clearly true as can’t get a flatworm to do it. When trying to debug really clever code the easiest solution can be giving up and starting from scratch.
- hasty_pudding 3y agoI think good software like good algorithms is made from simple patterns that do complex things.
- Grimburger 3y ago> The last thing you want to do is to throw a million of abstraction layers, frameworks, libraries, precompilers, transpilers, build steps, validation hooks, style checkers etc. into the mix. Each of them makes your project more complex by a certain factor. And not only do they add up - they multiply! Know plenty of people who call this job security
- dickersnoodle 3y agoIt's worse if your team uses a house-built framework that's too complex for its own good. There's a whole team devoted to the care and feeding of a framework that could be replaced with source code templates or just a clear architecture document with a "cookbook" style set of accompanying documents. God forbid you try to use something else; you'll get inundated with "But that's the company standard!" style job protection complaints.
- sjducb 3y agoThis is so hard in practice. I just had a junior dev rewrite some of my code so that: a builder calls a constructor which instantiates a builder factory which builds a builder then that second builder creates the object. This whole system only builds one type of object. He thinks that his solution is better because it’s more extensible. I can’t make him see why it’s bad.
- AnimalMuppet 3y agoMake him maintain one that someone else wrote.
- mgkimsal 3y agoOr... get them to maintain their own code 14 years in the future. Hard to do in practice, but once you've done it, you get a new perspective. I got a call from a guy saying "hey, this broke". I had not touched this system in 13 years. I had to re-remember a bunch of stuff. Some of the code was still a joy to work with. The parts that were hard were... obvious, and even then, I remember cutting corners, not documenting stuff, and overcomplicating things "just in case" (which mostly never happened). There's little amount of someone 'telling' me ahead of time how much difficulty I was leaving for the next person (or even myself). It really seems like the only way to get this experience is with time. That doesn't mean you can't follow some best practices that turn out to be beneficial. But until you've experienced the downsides, you won't really be able to internalize the why regarding something being good or bad.
- ziml77 3y agoThat or make him try to maintain his own code a year later when it may as well have been written by someone else. This is really the only way to properly understand the problem with making all those abstractions. It all makes sense when you have the whole structure in your head but it's very hard to build that mental model back up later.
- jvanderbot 3y agoPremature generalization is the root of all evil nowadays.
- havkom 3y agoGreat advice! I wish more people had that insight nowadays.
- snodes 3y agoGood advice; it improves maintainability, which becomes even more important the larger a codebase becomes. https://grugbrain.dev/ https://grugbrain.dev/ talks a lot about avoiding complexity, and does so in a pretty entertaining writing style too.
- nvarsj 3y agoKnown as the KISS principle - Keep It Simple Stupid! Taught to me at university 20 years ago and still valid today.
- deleted 3y ago[deleted]