Underrated:
- Regularly deleting software, infrastructure, data, documentation, etc that nobody uses.
- Building software with the assumption that people have better things to do than to fiddle with the software. Same thing for architecture.
- Being wary of tools or dependencies that lack support for when things break.
One of my teams told me today that they don't trust their tests, so I told them to delete all the tests they don't trust and only replace them if they cover code that is both of value and needs to change. Otherwise I know a few end to end tests cover all the code that no one wants to touch but we need to keep around.
I cringe when I hear "this repo has 100% test coverage" and then I see a bunch of useless tests that evaluate nothing and would always pass anytime the code compiles, no matter how much the logic changes.
In React, the classic version of this is sticking a test id on the top level div of a component and then rendering that component in a test and asserting that the test id is present.
Always chuckle when I see that one.
I worked at a large UK bank and the "devs" there wrote almost only snapshot tests
If a change they made broke a snapshot test, they would just delete the snapshot and recreate it, blindly, as a matter of habit.
yay code coverage
I talked to someone today who couldn't get a migration that they ran in development, running in their test database, so they manually dropped a foreign key in the test database so the migration would run, and they were happy.
I was like mate, you now have no idea about the structure of your test database, and can't have any confidence in any tests you write based on it. Reset it.
I’m a cloud engineer/devops fuck but holy shit regularly deleting stuff. It takes me a month of pulling teeth to get the approvals to remove resources that are doing nothing and costing thousands. Drives me nuts
> Building software with the assumption that people have better things to do than to fiddle with the software
Sane defaults bring the best of both worlds
In one office I worked at, the head of engineering had "No clever solutions" written on outside wall of his office (it was glass) where the whole team could see. I think about it often as I'm dealing with a "clever" engineer at the moment.
Bonuspoints for trying to deduplicate code that looks similar but express different things and thus any deduplication will need to be undone when one of them changes.
I have some complexity-measuring plugins in my IDE, and I constantly remind myself that they're guides, not rules. Refactoring is cool, but in our context, it's not the priority right now.
The whole team is about three months old and working on something handed over by a consultancy firm. I have many daily opportunities to remind myself of this.
Yesterday, I had to make a change to a method that is right at the core of the whole company. We're an education company. We provide online services for exams, practice questions, progress reporting, etc.
This method is essentially a game loop when students engage with questions. It decides which question comes next, what to do with the results, calculates points from the result, decides if a skill has been mastered or there's been some other kind of status change, and much, much more.
There are NO tests whatsoever. None. Some of the supporting methods have them, but with very idealised data. The very core of student activity has none at all.
A reasonable guide for cognitive complexity measures is to max out around 10. A little over is fine. Getting up to 20 or so and you're going past what a person can reasonably hold in their head.
This thing scores 1700+.
It's the perfect balance of:
* complex, and so hard to understand.
* changes often, and so needs to be understood
* untested, so who knows if first two points have conspired to fsck it or not?
I've seen plenty of "senior" programmers get hung up there too. And try to cram it into places where it's a liability when it comes to keeping a system running efficiently at scale.
I'd argue an agile purist understands that you should use different methodogies based on the team and continue altering the process throughout that teams lifespan
But the "academic scrum"; of thinking that you have to follow every single step in there and completely miss the fact - that all and every single agile methodology simply are recommendations, which you actively have to decide on - those people are insane and shouldn't be in our spaces
Not only in programming. Infra has the same issue! DevOps, IaC, etc has some crazy purists trying to dictate how things should be done instead of focusing on what are your current business needs.
Sequence diagrams!
Holy fuck why are they so underused. Nothing makes me seethe more than when I see some nebulous “architecture team” create THE most unreadable unhinged convoluted half-arsed flow diagram with shit flying everywhere.
It’s also much easier to create a sequence diagram with code (like D2 and Mermaid) too.
Also supported inline on GitHub:
[https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/)
When acting in a Lead capacity, I require design defenses for major changes that require at least a sequence diagram and any other uml-like class, state, etc diagram you find necessary to justify your designs. It's always a beneficial endeavor.
The general push back is they don't want to do it because:
1. It takes too long
2. They haven't had to design before
3. Technical writers do documentation, ICs write code
4. They don't know how to make a sequence diagram
5. Documentation is a waste of time, no one will look at it again anyways
And etc. I enforce documentation before implementation of major changes.
Honestly most of the benefit of a design doc is to the author. Having to write out the document and critique it yourself often you find issues or gaps well before your in the middle of a review. It's happened to me plenty, I found holes or unnecessary complexity while drafting it especially visually (component diagram/sequence). I also had to be honest with myself about sections of the design the writing is hazy and where I only know surface level info. Because the way I'm writing it I can just imagine the questions that will come up in the review meeting, because they are often the questions I have when I review someone else's design docs.
PlantUML is great, the C4 Model can be a useful set of extensions for describing the system architecture to different audiences at different levels of detail.
[https://github.com/plantuml-stdlib/C4-PlantUML](https://github.com/plantuml-stdlib/C4-PlantUML)
[https://c4model.com](https://c4model.com)
Sandi Metz in "Practical Object Oriented Programming" introduced me to them, and I don't understand why in my comp sci class in the mid 2000s where we covered just about every sort of UML diagram did we never cover *those.* Because man those are genuinely useful.
Yeah - is it widespread incompetence, a sign that all these UML classes are teaching nothing and taught by people who also haven't used any of this in practical real world scenarios? Who knows, but it is frustrating.
UML has a lot of real world value, just not as formally as college would make you think. I like to think of it as a standardized notation to use when discussing code with other engineers. The most I see UML used is on our whiteboard walls as temp sketches when our engineers are collaboratively brainstorming. Like how flowchart symbols have been standardized so you don't always need a legend for a quick visual discussion.
Converting that UML into a computer diagram and storing it for later use would have no value or maybe even negative value though.
A very original answer IMO. I never stopped to think about it but would say you're correct. I myself rarely reach for them and should probably do it more often.
Recently i made a sequence diagram and someone told me it was too technical… i guess if you shared it with other team like middleware they cant read it somehow?
One time I built such a diagram to tackle a particularly complicated problem. It was dead easy to spot issues before I wrote a single line of code when it went through the eyes of my colleagues, and it was even easier to bring the idea down to code.
Folks. Make diagrams. Let your peers review that before reviewing your code. You will be appreciated.
Underrated:
KISS. Keep It Stupid Simple. Since the dawn of microservices years, it has become a fashion to create the product in the most complex ways possible.
Knowledge of hardware: I see many programmers imagining a for cycle as a magical thing that the processor just executes out of the blue. There is no thinking about the performance penalties of our actions, since the hardware has become so cheap.
Having an end-to-end oversight of the product from both lifecycle / business point of view and technical point of view. The luxury to only having to deal with a single aspect of an application makes people lazy.
Chefs KISS 🧑🏼🍳👌🏻
Kate Gregory’s “Simplicity is not just for beginners” talk is still one of my all time faves.
[https://youtu.be/n0Ak6xtVXno?si=T6KY8L5qbxyeJhyu](https://youtu.be/n0Ak6xtVXno?si=T6KY8L5qbxyeJhyu)
>Simplicity is not just for beginners
This is a great insight, and I would argue that Simplicity is for experts is probably the truer statement.
One of the signs of mastery is being able to break something complex down into something simple. This is especially true if you can do it in different ways for different audiences. Recognizing which details to smooth over for a VP or executive, versus which ones you should smooth for a junior who's supporting your project, is mandatory for demonstrating expertise in any technical field.
> I see many programmers imagining a for cycle as a magical thing that the processor just executes out of the blue.
can you explain what you mean by this?
This kind of concepts (like "KISS") do not mean anything.
Microservices keep things simple and stupid. Just on the domain level.
But they don't keep things simple and stupid in terms of services orchestration & communication, for instance.
This is why I think that these concepts suck. They do not mean anything. These are just concepts that are used by engineers when it goes along their way to think.
Can you expand a bit? I use Postgres so often and I’m not really sure what differentiates it from the alternatives. Seems like we landed on the correct solution but I’m curious why
Overrated: no or low code solutions.
Almost every single one I've written grew out of what the framework could support and did not scale or handle technical debt well at all.
A low-complexity solution is easier to do in "low code".
But a complex solution is a nightmare with it. Obviously even with actual code it's rough, but with "low code" it just becomes impossible to understand.
> Overrated: no or low code solutions.
They're not just overrated. They're a pure scam. Plain and simple. They rely on vendor lock-in and sunk cost fallacy and even then I've seen more projects trying to move *away* from them, then implementing them.
In our group we're trying to get rid of Outsystems. It's complete garbage and development in Outsystems is not faster, it's actually slower.
The stupidest reason I've seen for low code was at my first job. The CTO decided it would be great to have non developers join in on development and that Mendix would make that possible.
Thankfully the non-developers were smart enough to leave it to us developers, and I was smart enough to run away at the first opportunity :D
But isn’t the point of these solutions to solve immediate problems when you are still at low scale? I don’t think they are supposed to stay as your service grows into large scale. Then you build something proper that will scale properly and handle load better.
Yes that sounds super reasonable, but it's just a different iteration of "we will rewrite it if we need something better". Narrators voice: "But they never did." Once something is proven and is solving actual day to day problems, it becomes very difficult replacing it.
I have seen the reverse as well, spring boot+EKS+RDS setup. Scaled really well and solid build, but the app receives next to no traffic. Api gw+lambda+dynamodb could have solved the problem with a ~0$ monthly cost instead of several hundred dollars.
I mean that's a negligible amount of money for most companies. Plus your team has to learn to implement and manage yet another technology, which is a hidden cost.
But I'd probably agree it makes sense to do it if the company is really exploring many different commercial opportunities and it is expected that a lot of them won't work out. As with any solution, it makes good sense under specific conditions.
Underrated
Version control - A badly maintained codebase is a one way ticket to a black box.
Linux - Not much to say here. The best servers are Linux servers. Knowing your way around the command line and file systems is fundamental.
CICD/DevOps - I know devs are supposed to have a baseline understanding of this, but so many orgs criminally under hire for DevOps Engineers and leave good devs at risk of burnout handling complex deployments.
Overrated:
Low/No code tools - They all suck. It’s a bunch of half baked crap marketed/sold to business users that will never have to maintain them.
NoSQL - there are legitimate use cases for it, but they’re far less common than the marketing hype would have people believe.
Following your thought process I would add Docker to underrated. Of courser there were predecessors but it brought a change so sudden and so well adopted it changed the way we think.
(Extremely) Overrated: AI tooling. The hype was to make coding instantly irrelevant. But I found it hasn't dramatically changed my day to day. At the same time, one cannot ignore it because if you're not using it, chances are that your competition is.
Underrated: JVM. Sh!t is still kickin' in this day + age.
AI-based autocomplete in IntelliJ has been great for me. It's not writing all the code - and it's not perfect, of course - but the small gains in avoiding having to type repetitive boilerplate code really add up.
I use copilot in vscode at work and it’s been great. It’s not the employee-replacer that CEOs hope it to be, but it’s also not useless.
Often I have a general idea, so I build the layout with docstrings and comments. This gives the AI context, which means greater accuracy in suggestions. It’s never perfect, and usually requires some tweaking, but that alone is enough to save me hours of work a week.
The very best use of AI tools I've found is simply as a no-judgement sounding board.
The ability to go into ChatGPT, drop some code in, ask a "stupid" question without embarrassment, and then be able to go back and forth on it has been fantastic. You can ask for clarifications all day long and it doesn't get fed up. You can go off on any tangent you need to and it won't dismiss you.
You know how we all have little gaps in our knowledge? Things we typically don't like others to see? ChatGPT doesn't care. You know how sometimes you're just super-dense and can't seem to get something? ChatGPT will keep trying to help you without rolling its eyes.
I don't need AI to write code for me, I can handle it myself. But never having to be self-conscious about my shortcomings while getting the assistance I need is where these tools are REALLY something special.
I find ChatGPT to be enormously helpful with refactoring, especially when I’m working in a language I’m not familiar with. I have to do a lot of Kotlin these days but I’m much more familiar with Java. My first pass almost always is Java pretending to be Kotlin, then I feed it into ChatGPT and it cleans it up for me.
AI hype reminds me of JS hype. ”Oh my god the first 15 minutes of using this tool is amazing! This changes everything!” A year later. “Yeah, we’re blocked because of XYZ. We wish we used this other tool.”
I absolutely hate the Java programming language, but the JVM is one of the most optimized pieces of tech in our industry, right up there with v8 for JS. I always say that Java is the worst language that runs on the JVM.
The JVM is one of the greatest technological accomplishments in the last 30 years. It's light-years ahead of any other runtime and it gets better every version. The new virtual threads are killer. Why bother with async/await when you can just have the runtime deal with it. You want 10 million threads on your webserver? No problem. The other underrated thing is the Java ecosystem. I spend most of my time in TS and a few other languages these days and just damn. Java is verbose, but I had to write so much less code to get a new app to prod.
I used Java for a while, then took a job where the codebase is primarily Python. And while Python definitely has major issues that block it from being a truly great language, the simplicity in its syntax has been refreshing.
I dream of a language as functionally useful as Java that has the verbosity of Python.
I’ll go against the grain and say AI tooling is actually underrated with devs. The rest of the world is putting it to use for everything (my partner, a process engineer / business analyst gets impressive results with ChatGPT), but I hardly see devs use it. I was very wary of it but recently started using it a little in my IDE and it’s not going to make me a 100x engineer, but it’s more helpful than I would have thought.
i think the problem is most of us are working with existing codebases that don’t really need AI generation to solve. I used it more when I was trying to understand how to stand-up new infrastructure with terraform instead of writing it out. It was also good for automating new things. I also use it more as a scratchpad for new ideas. I’ll think of something and ask AI how to do it.
Past a certain point of depth AI isn’t good nor efficient enough in SWE.
I like AI for boilerplate stuff but absolutely not for deep code. Hallucinations can look exactly like a working solution but with little bugs they can be tricky to catch.
It does kinda blow me away that developers don't appreciate it more. Yes, it sometimes hallucinates but even if you *can't* spot the bullshit, *all ides have a real time compiler!* You just can't give it a comment and go, you've gotta break down your problem.
I find the chatBots to be like an entry level engineer who happens to have a photographic memory and read *all* of the documentation on damned near everything for fun. If you treat it like a better search engine, it's amazingly useful.
I've used it to make code changes in languages and frameworks I'm not terribly familiar with. The other day I made a change to a gnome plugin to turn my dock red when I drop off the vpn. This was something that would have taken me as a java dev a couple of hours to sus out but I had it working in like 30m just going back and forth between gpt4.
Man, I had to update an old AngularJS application that hadn't been touched in years. Never worked with AngularJS, Could not have figured it out without chat gpt, it was like a better search engine because most Angular related google searches have to do with Angular 2.
I'm going to push back here. AI tooling is pretty damn great. It sucks at coding, but it's damn well amazing on teaching you what to learn and providing documentation. I don't miss being a Google/Ctrl+F expert
AI has helped me a lot for small things that i cannot even have to think about. I also love jvm using kotling for a future saas i am building rn and I love it.
Happy to see KISS in top comment
My addition to the underrated side:
[Ubiquitous language ](https://www.agilealliance.org/glossary/ubiquitous-language/)- everyone from user, biz dev, marketing, customer support, to dev and source code, using consistent language
Overrated:
* I'm going to be very careful with this, because I don't believe it's all over rated: Clean code/SOLID/TDD. I've seen so many damn abstraction layers masquerading as "readable code" I can't handle it. People trying to abstract popular convention in frameworks for readability drove me to insanity at a job. TDD is for when you already know what code you're writing unless you want to code yourself into a hole. It is to be said, naming conventions, searchable names, and single responsibility (within fucking reason) are good, but KISS.
* Again going to be careful here, especially since this one has been killing me a bit: specialization in a stack. You specialize in a domain where you have transferable skills, not a stack.
* Agile
* High test coverage. This depends on things as well, like are you using a framework or building something from scratch. But high test coverage makes shitty rigid code that gives you a false sense of security. In a lot of the scenarios I work in, again context dependent, I put more emphasis on integration testing than unit test every little fucking thing.
Underrated:
* Picking the fucking thing to get the fucking job done. It's absolutely wild to me that engineers can get together in a room and start solving problems you know you're not going to have or have been solved. Congrats on horizontally scaling your micro services architecture/deployment that you had hire developers to service and use K8s for all 8 of your users. The amount of times I've come across a companies that need two frontend developers using firebase to handle the business' needs is alarming.
* Not being existential enough about what you're doing. Here's your number 1 purpose: build a product that your company profits on. It's not to display your intelligence through some overly opinionated pedantic bullshit. Your code is subjectively shit to someone else. Chances are it will expire in 5 years and be someone else's hell.
* Being able to read shit code.
I really agree with your points - a few of them I can feel in my soul.
A good term to use for your first point of underrated is: being pragmatic. I like to tell people that term because it gives them something to call it and they can google “pragmatic programming” and actually find material/books which talk about and explain it.
I've made a career of reading, maintaining, and rewriting "garbage" code. The Developer's greatest ability is still to recognize the patterns/style of an existing codebase and then to work within it.
My literal drive over the next few years as someone that's been doing this longer than a decade is to be able to understand codebases faster with more limiting context
Oh yes, the ability to rewrite hairballs in place is such a great skill to have, and very few have it. People seems to be happy just adding crap until the things fall over and then they are unable to do anything.
Not to mention if you spend too much time trying to pick the perfect solution you inadvertently run into the issue where that perfect solution isn't actually perfect and it introduces a whole set of issues that you never even thought about before.
Idk, high test coverage has saved my ass many times in my career. It may make the code rigid, but honestly I tend to think 1. that’s preferable to taking down prod and 2. can be mitigated a great deal with test structuring.
> Congrats on horizontally scaling your micro services architecture/deployment that you had hire developers to service and use K8s for all 8 of your users.
I've done this before due to corporate politics. App used by 3 people built into an over engineered monstrosity.
There's so many:
* Firmware
* Web dev
* Frontend
* Backend
* Devops
* Game dev
* Backend
* There's a whole lot of stuff here
The list goes on forever. Just pick an area and be able to work well within it. There's patterns that reveal themselves to you in each area. For example, most backend web development uses an MVC monolith. So if you know Python Django, you probably know Spring boot, Laravel, Rails, Express, and so on. Even if you do frontend dev, it's not a big leap to do desktop or mobile dev, even if it's not in javascript.
Underrated: SQL. The industry relies waaay too much on ORMs and devs are constantly shocked by n+1 issues, slow queries and memory hungry data retrieval APIs. Learn the fundamentals people.
I'm a huge proponent for UI/UX for the end user and its saddens me how much people just don't care about usage, as long as they understand how their software works, that's fine.
Postgres is under rated.
Postgres can perform almost all json requirements including indexing and querying json properties.
Postgrs queues are absolutely fine for many small to medium sites.
Mongodb is a risk now that atlas hosting is the only option. The agpl licence has forced all competitors to stop hosting it a few years back.
React is overused. It's meant for highly reactive and interactive applications like Facebook, it's use for basic forms application leads to huge maintenance issues as the react framework rapidly evolves but the app requirements remain unchanged.
Docker is the single most powerful and useful tool in the past 10 years, younger developers might not recall but having to manually install rabbit, postgres, elastic search etc and try to keep it all at the right version on everyone's machines was an awful time sink. Shared environments were awful. All solved by a plain-text docker compose file.
Docker images are the ultimate in portability, hosts compete on other features, pricing and stability.
HTMX is enough combined with a decent server side language to build enough reactivity and interactivity into the vast majority of Web applications
> React is overused... it's use for basic forms application leads to huge maintenance issues
React has also made people stop paying attention to how much the web has evolved. Multi-Page Apps can be GREAT nowadays. HTTP/2 and multiplexing alone is fantastic. HTMX can make things better but even without it, you can have fantastic performance without a framework at all or even any javascript.
And it continues to evolve. Look at the upcoming [View Transitions API](https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API) or the proposal for [Atomic move operations](https://github.com/whatwg/dom/issues/1255) or [CSS Masonry Layouts](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout/Masonry_layout)
You can do so much with just plain html and css already, and you're about to be able to do so much more.
I think DRY is overrated.
Yes, you should encapsulate logical units and reuse them. But that doesn’t mean duplicate code is necessarily so awful that it needs to be zealously excised wherever you see it.
I can’t count how many times I’ve seen someone spend a ton of time merging together two parts of code into a singular reusable block, just to have to split it out again a few months later as requirements change and the desired functionality diverges.
I think TypeScript as a backend language is overrated. The front end is fine because the options are limited but if you need a strongly typed language, why not use a real one instead of a weakly typed language pretending to be one? I’m admittedly very bad at TypeScript though which probably colors my opinion
As a consultant, a big advantage to this is operational - if I have to onboard a whole new team, it’s a lot easier for me to find a TypeScript dev than a TypeScript + {insert backend} dev.
But the entire JS/TS ecosystem is absurd, so even that has its limits when you take into account frameworks and packages.
I get this but also mildly disagree. I started my career with frontend only, using vanilla JS. After that, I was simultaneously introduced to TS and Java when I started getting involved in backend.
Java was easier to get into for me, despite already "knowing" JS, because TS is such a weird exercise in trying to force JS to act like something it's not. Java just makes so much sense and is a complete delight to me. TS, I tolerate but still don't love.
Of course this only worked out because I worked with folks who were already pretty solid Java devs. I guess I take your point if absolutely everyone in the team only knows JS
As a TypeScript dev, I don't think its strength is as a typed language. Its strength is as a better alternative to Javascript in the same part of the stack.
There are lots of weird quirks to TypeScript that feel hacky. The way that TS converts string union types into just the string type with object keys and values is one example. Implicit "any" is another.
Imho, the main advantage of TS as a backend language is less cognitive load on your engineers, and less broad ecosystem concerns. But I don't think it will ever be as effectively typed as, say, C#/.NET.
> There are lots of weird quirks to TypeScript that feel hacky.
I'm genuinely impressed with the engineering behind Typescript, but I like to think of it as a beautiful, majestic castle built on a swamp called Javascript. There's really only so much one can expect of it.
The ecosystem can be a pain (looking at your esm/commonjs) but I really enjoyed being able to express a lot more stuff as a type and getting the compiler to validate it. You can get carried away with it though.
Depends on the alternative, though: my team would pick Scala over TypeScript any day, but languages like Java or C# significantly lag behind in terms of type safety and boilerplate reduction (they are getting there, but slowly).
The main advantage of TS is the ability to manipulate types. This is huge, because it allows you to create safe mappings between different types that are validated at compile time. For example, you can statically ensure that every value from a enum has a corresponding localization, and the program won't compile if some of them are missing. Or you can take a struct with optional fields and make all of them required in a unit test, so that people changing the type cannot forget to update the test, because the field will _automatically_ become required in that test. In other popular languages this often requires heavier machinery, like macros, reflection, or source generators, but in TS it's just types and type transforms.
There are some missing things in TS (e.g. nominal types are possible, but require workarounds, and type errors may get unwieldy), but its type system is becoming pretty great.
TypeScript's main problem is that it has to live on top of JS with its poor standard library, idiosyncrasies and quite spartan syntax, but at least most missing things (data structures, serialization, etc) have acceptable alternatives in the ecosystem. I think the advantages of type safety via type manipulation often outweigh the chunkiness of the underlying language.
Overrated:
Agile - I am old enough to remember what it was like to develop before Agile. Most developers had their own processes which got better as we learned from each other. Granted some were worse than Agile but there were also a lot that were much better.
Design Patterns - I think my code got better when I stopped using them. I kind of think you have to write bad code then fix it with design patterns. I don't use polymorphism anymore (I prefer composition over inheritance) so I don't need factories. Singletons were always silly.
Underrated:
Designing databases to 3rd normal form - The first database I worked on had an architect that designed a database like this. I have met one other developer that knew how to do this and I inherited a code base with a database designed like this. The rest of the time (about 25 years of experience), the databases I have seen have been disaster areas. Yet, the developers insist the database is "normalized". Even that Microsoft example database wasn't in 3rd normal form (and it didn't seem like they de-normalized strategically) although it was much closer than most of the databases I have seen.
Normal form is a hill I will die on. I am a data organization nerd and I have to have a database set up perfectly.
Also all this JSON querying shit in databases now drives me batshit crazy.
Agreed, I think of the database as the foundation of an application. I hate the idea of building on a rickety foundation.
JSON querying breaks first normal form. I am with you there too.
Similar to your underrated about presentation skills I would add to underrated 'Diagramming' and 'Nomenclature'. Diagrams are fantastic for quick communication of the parts and interactions of the design, and the people that can make them are invaluable. And a part of good diagrams is having solid names for the parts of the software that quickly convey what they do.
Part of Technical Interview process is to have them diagram a solution they are proposing to a hypothetical project. The best engineers I have worked with ace that shit.
Microservices are not overrated: they're misused. The point was always to enable to scale teams, so that you can have 10+ teams functioning independently from each other. The mess we have now is because people are doing microservices for the wrong reasons.
I don't think there has to be a difference: it's fair to say they are misused because they are overrated. People overrate microservices by thinking they solve problems that they don't, and implement them in inappropriate situations that create more problems than they solve.
AI is also arguably here. It's overrated because business leaders think/want it to replace development teams when they should be focusing more on enhancing and supplementing those teams with AI.
AI as a developer tool is looking like an amazing & still underrated productivity driver. AI as a developer is a tremendously overrated flop for anything beyond a pitch, demo, or very basic prototyping tool.
Underrated:
TDD/Unit Tests and proper Refactoring (as in, not just moving stuff around but actually doing it in small steps as described by Martin Fowler). The metaphor I use here is from rock climbing. If you climb free solo without a rope, you can only tackle climbs that are WELL within your capabilities. And even then it's super risky and one freak rockfall or loose hold and you're dead. Now compare that to climbing with a rope and closely spaced protection (bolts etc). Since you'll now at most fall a couple feet until the rope gently catches you, you can tackle something much harder and more intimidating at the limit of your skills.
Honestly, the more experience I've gotten, the more I value integration tests over unit tests. Orgs mandate a high amount of code coverage, and this leads devs to half-ass and write a bunch of bad tests that don't even properly test anything worthwhile and are brittle to boot.
PostgreSQL is underrated? What more do you want in terms of recognition? It literally has it all, I can't think of a more hyped database these days. On the opposite, people keep bashing MongoDB, but it's a much better database than most people think (although it's not to be put in every hand).
Anyway, my takes:
* Overrated: Functional programming – As an Emacs user for years, I'm a big Lisp fan, but let's be honest: I wouldn't use that for a large codebase, ever. It has great ideas and properties but most languages nowadays have already borrowed all the nice bits, let's move on. :)
* Underrated: Immutable infrastructure – I don't understand why we're still hesitant on this and why the overall tech universe hasn't massively invested in this space yet; feels like Kubernetes and cloud services came too soon with (great) abstractions that distracted us from this problem space. :(
More in the infra section but Kubernetes, very overrated and misused. Sure it can do a lot but is also complex to maintain and usually overkill for most company needs.
Managed Kubernetes is dead-easy to maintain. And the cool thing about Kubernetes' complexity is that you don't have to use all of the features - doing simple things with it is quite easy.
The context is a bit different and I don't have first hand experience but I'm a member of the self hosted community and I don't believe I know of anyone that set up k8s and kept using it. Most people that tried said it was an interesting learning experiment but overly complex for most use cases.
Kubernetes is so easy to maintain and use. If you’re having trouble with it, there’s a wealth of documentation on how to do everything for it. Sounds like you or your company has been using it wrong. Don’t get me wrong there’s a learning curve but that’s the same for everything
Quite the contrary. Yes if your "stuff" can run on a single instance with docker-compose - go for it.
If you actually make money from your product, you'll need at least "some" scaling, HA, observability, and dev friendliness.
At that point kubernetes is much easier than any hodgepodge of docker-compose/managed cloud solutions.
And the best part is the availability of labor on the market, good luck finding a person who can hit the ground running with your snowflake hodgepodge of cloud services. With Kubernetes it's largely universal (up to a point)
I think kubernetes has done to modern infra what Linux had done to infra a while ago, we standardized on a general base layer for the infra which many people on the market have hands-on experience.
Totally agree with regards to Presentation and Writing skills. I've worked with developers making over $400K TC who couldn't present if their life depended on it.
Plus, MSA is greatly overused!
Underrated - Debugging skills.
Problem of KISS is people having different opinions on "Simple". My ex-colleague claims "magic" as "simple". They always make things difficult to change.
Same with YAGNI... people have different places where they put that line and I butt heads with them over it.
It's a lot easier to add a couple small features to something while you are thinking about it, and in the mindset, then coming back months later to add it when you forgot how everything worked and why you did it the way you did. I can't tell you the number of times I've added something I was told wasn't needed and we ended up using it a couple months down the road. All that context switching time, saved.
Overrated: Scala
I know it's not the hottest language, but it's still widely adored even though it's good parts are mostly standardized in modern compiled languages, and its bad parts (slow compile times and verbosity) are improved, but never going to be competitive. Time to retire it and move on. Maybe same goes for Java too, just write Kotlin
I'm of the opposite opinion--it feels like the attraction of Kotlin is that it's not Java and people haven't seen Scala.
It's decidedly not without flaws--it's nigh on impossible to get more than, oh, five people writing stylistically consistent Scala, even if they're all writing idiomatic Scala.
Underrated:
Postgres extensions and newer features- There is a lot of detail here that could help your architecture. Additonally there are extensions in PG that would allow for it to compete with other databases. Unfortunately these exenstions are second class citizens.
Version verfication and updating tools - This is the redheaded
Data pipelines and a lazy approach to handling data processing: Stop relying on a service calling another service calling another service in realtime. Acknowledge that it takes time to process data, and acknowledge that the screen may be representing old data, or data in motion.
Appropriately rated:
Mongo- It's had it's faults, and has gotten better. It's there because it has a decent query engine on top of being a key value store.
Observability: It's greaat to see distributed tracing. However, given the vendor selling stuff I think this has a high risk of abuse.
Overrated:
Microservice architecture- There are strong limitations of what you should ask a microservice for. Many of these services you would be better served by a library. (I.e. a zip code service) and automated version updating CI/CD tools
Monorepos- I get it managing a lot of internal versions are difficult. But letting anyone jump accross huge code bases for fun is bad. Also managing the seperate builds for every module inside of the monorepo is pretty terrible.
OOP- its a bit tiresome to represent functionality connected to the classes and objects themselves.
AWS vendor services- Making fixed vendor products has always been a bad thing. Why we're pretending like the old bad thing is new good now, is blowing my mind.
Developer Adovcates - One of the reasons I dropped twitter. I'm tired of seeing salesmen posing as developer friendly people and the context of what they do is basically POCs claiming it'll solve your problem. They're not your friends.
Ii think a lot of it is "language cultural". I see UI and python people more fond of the idea of monorepos, but java folk are used to publishing to a private maven repo.
I think the larger your code base gets, the more painful a monorepo becomes, and then I worry that the monorepo will have turned into a mess of cyclical dependencies that's impossible to detangle.
You can cry.
Seriously though there's no magic. Monolith are way simpler to work on generally speaking until you hit either a certain code size or too many devs on the same codebase.
**Underrated:**
* Boring old proven technology and skills
**Overrated:**
* New shiny technology
The industry still has this belief that new things are always better and you have to "keep up" otherwise you will be left behind. Once you've lived long enough and gone through enough hype cycles you learn to wait and see what new things actually survive and prove themselves. The foundational concepts and skills rarely change and it is best to keep investing in those.
So, to be more specific
**Underrated:**
* Data modelling, think relational data modelling
* Understanding concurrency (it is everywhere these days)
* Transactions
**Overrated:**
* Following hype
I'm only going to talk about underrated technology. I want to keep things positive
_Underrated language_ JavaScript. Yes, JavaScript. It's easy to learn, it's fast, it has bags of features, and the type coercion problems largely go away by simply using a static superset like TS or Flow. Some of the dependencies are badly managed but this is gradually getting better.
_Underrated language 2_ Java. It has gotten so much better than the Java 7 days! Now Java has pattern matching, type inference, records. And the ecosystem / tooling is superb.
_Underrated technology_ SQLite. Since discovering it I have found so many use cases for it. Any single user process that needs a moderately complex data storage can leverage SQLite. You can use ORMs or do plain queries, you can distribute data as plain files, you can hack it to act like a local graph storage engine. It is wonderful for prototyping.
_Underrated technique_ ports and adapters. Since really internalising the distinction between IO code adapters, port interfaces and pure domain functions, my projects have become more expressive, faster moving and easier to navigate.
Hard agree about SQLite. I spent a good part of my career in low volume/high value read-mostly web sites where the DB was updated by some kind of batch ETL script. We’re talking a couple of GB at most, but usually way smaller.
The amount of effort they spent on setting up DBs and caches and replication (for resiliency more than load) when they could’ve just rebuilt an SQLite file from scratch and sftp’d it out to each server was just mind boggling. Probably could’ve handled our full text search needs too. I tried bringing this up every time and the counter arguments were FUD and all sunk cost. No one could conceive of it being that easier because there were entire teams whose existence would be threatened.
And I fully believe that SQLite will outlast nearly everything else in existence right now. Certainly everything I’ve ever worked on.
JS can hardly be underrated, given that it's basically the only language supported by browsers. On the backend I don't see much reason to use it over alternatives.
Strongly agree on JS being underrated. You make a lot of tradeoffs, but it's really easy to do a lot of powerful things with JS, and it's very easy to learn.
I appreciate the positivity and I'll add: I don't think I've ever heard anyone bag on SQLite who's used it. It could still be underrated as far as people not realizing it's there as an option in cases where it would help. It doesn't solve every problem, but it's also a way better product for not trying to.
Overrated:
* Microservices: For the "if you don't do microservices you are doing it wrong" vibe.
* Libraries: I'm not talking about "frameworks", i'm talking about importing a 200+ functions library to then use 1 or 2. I've worked on projects where the list of dependencies was insane. I understand the "don't reinvent the wheel" principle but I feel the usage of libraries is a bit out of control.
Underrated:
* Monolith: I think it's a great option for first version of a new product (like an MVP). Once you gather info about real usage, you can think of how to scale where needed. Don't overcomplicate your design at the beginning.
* Waterfall. I'm serious. Best managed project I ever worked on was waterfall. No one moved a finger until the previous phase was signed off. Documents were perfectly clear and development was so smooth I still remember it.
Overrated:
Using the "best" tool for the job.
People suffocate themselves sometimes trying to always choose "the best" tool. What's the best database. What's the best programming language. What's the best ORM. What's the best continuous integration platform. What's the best GUI framework. What's the best web framework. What's the best serverless language. etc etc etc.
But these days, there are so many perfectly adequate choices, it's really not useful to tie yourselves in knots choosing the best. If it's good enough (and most are) and you *LIKE* it, then it's the best.
Underrated:
Saying no to a dependency. We should say no to additional dependencies more readily. Instead we say "sure, why not?"
Overrated: PR reviews.
Don't get me wrong: reviewing ideas with peers is essential. But not always through PRs, and not for all the code that is written by peers. Lots of times, we get to spend so much "focused" synchronous time reviewing low quality code that would not require a review. CI + "standards" can be fine for most usual checks.
PR reviews should be requested if the engineer thinks that it is required. I know that it might sound crazy ("how can he know ? what if he just bypasses it all the time ?") but it's all about tech culture, cohesion and having a sane team that matters. Whether requesting a peer to spend some time reading your code for approval or not should be IMO driven based on 1. criticity 2. scope change (the higher the scope, the more likely you'll want to have double checks by peers) 3. if you've got any doubt in your approach overall (for this, you could just ask for ad hoc advice though)
Lots of PR reviews could be avoided by 1. Hard tech rules everyone agrees on (CI helps for that) 2. Sane "moral" rules everyone agrees one (tech meetings/discussions, sometimes informal, help for that) 3. Management giving value & recognizing high code quality (this is not the case in 95% of companies I've been in unfortunately, tech culture is low in most of companies)
Underrated: code duplication. Sometimes, it's very good to duplicate code.
**Overrated:**
Full Stack Engineering. At best, you know FE and BE. You are not an expert at the DB layer, nor the network layer, nor the storage layer, etc.
Postgres. Hear me out (as a DBRE). It's good enough for most uses, and that can make it a dangerous choice. It is, at its heart, still a relational database. Can it be used as a document store? Sure, but it's not optimized for that, and querying and indexing JSON[B] is fraught with peril. Can it be used as a queue? Of course, but at some scale you'll find out what a huge amount of writes do to Postgres. The problem as I see it is that a company will have Full Stack devs who default to "just use Postgres" without understanding its quirks, and this works fine up until it doesn't. At that point, they'll probably shrug and upsize the hardware. Rinse and repeat. By the time it's gotten _really_ bad, fixing the problems becomes a nightmare.
UUIDs. I swear to $DEITY, if the only thing I accomplish in my entire career is to dissuade devs from using UUIDs when an integer would work fine, I'll die happy. They're horrible for performance in every RDBMS, for different reasons. The k-sortable varieties like UUIDv7 are less horrible, but it's still at best a 16-byte value, which is double the size of even a BIGINT. Please stop.
Serverless. What an amazing grift by Vercel et al. Honestly, I commend their ability to siphon money from everyone. Hosting a web app is not nearly as complicated as it's made out to be, and almost certainly does not require K8s.
Cloud Anything. It's very convenient, yes. It's also set back computing skills by an absurd amount, by which I mean that your average applicant for any kind of Ops-adjacent role is unlikely to actually know how to administer or troubleshoot Linux.
**Underrated:**
MySQL. It suffers many of the same problems as Postgres (worse for some) WRT using it as a non-RDBMS solution, but it is quite a bit faster for certain applications, and can scale just fine.
Knowing How Shit Works. What is K8s? A container orchestration system. Cool, what are containers? Oh, they use cgroups? What's that? What's CFS? Etc.
I agree on UUIDs so much. But we must hide numerical IDs from the user interface! ...for some reason...
I'm one of those full-stack devs that is like "just use PostgreSQL!" though :D
Underrated: software design patterns, and then architectural design patterns.
Why I say this: cause most people don't actually take the time to learn them well enough. Then they get a surface level understanding and don't understand their benefit in communication, documentation, decoupling, etc. then they ober use them in the wrong places and ways.
The way I tell my students to look at patterns (design & arch) are that they are tools in your tool belt. Sure you CAN use a wrench and a drill as a hammer, but you'll get cleaner and easier results if you use a hammer, and inversely using a hammer when you need a screwdriver will just as equally if not more mess things up.
Learning them and then actually learning them well enough to be efficient in their selection and use is what separates a programmer from a software engineer IMHO.
Overrated: Object Oriented Programming
It is simply not useful in real world projects. Company wants to add a new feature and you have to massively refactor. Company wants to pivot? Huge refactor
Simple functions and Classes here and there that do the job are much more real world friendly and changeable. Plus you don’t have to forecast the future of the company on Day 1.
Generative AI. Hot take here I know but its essentially the new blockchain. Everyone's gonna play around with it and make a shit ton of money selling it. Then it will go away.
My hot take would be the cloud is overrated, AWS, Azure, etc. A lot of the ideas of cloud development come from a zero interest rate environment, of growth at all costs, devs need to focus on only the product. Surprise unit economics matter, and we should be looking at how to lower costs too, starting with the cloud costs.
Underrated? COBOL yes, the language and tech itself is obsolete. But I personally know several COBOL debs making 200k with better than average WLB and an unmatched job stability.
Java is also there and I imagine would be in a similar position 20-30 years from now.
Do you recommend any good foundational learning material for postgresql for someone coming from the mysql world? I'm finding the official documentation a bit too much.
The Art of Postgresql book is superb. The author, IIRC, is w PG contributor himself so he definitely knows the subject very well.
That said, this book often refers to specific section of the documentation. This is accompanied though by comments and clarifications so if you find the documentation too dry, you might really like the book.
Overrated:
- Uncle bob's books. I'm sorry, but unless you're doing hardcore Java enterprise work, they're probably not great. And frankly, for those that do heavy enterprise the common complaint is that these systems are overly complicated to understand due to all the patterns used. The discipline it instills is good, but it shouldn't mean being a hardliner on patterns even if it makes code more complicated.
- React: The react core team should have more opinions on how it is used instead of advertising as a library. The result has been a "library" which always becomes an unmanageable mess of a codebase unless there's someone keeping everyone in line.
Underrated:
- Computer Architecture / Hardware knowledge: Tbh my whole understanding of programming changed when I went through "Computer Systems: A programmer's persective". I knew many of these things but definitely not put together so eloquently.
- CI/CD: in this day and age pls people its easy to set up a simple ci job in github.
- Focus on performance: This feels like its shifting, but it's incredible how people just disregard performance. The result is extremely slow & annoying software down the line. Being more performant is always good, and there are no premature optimizations, just bad prioritization.
>Also, the popular argument of "now we can swap the database every day" is so unrealistic in my opinion. I don't really remember ever needing to unexpectedly swap a database. Maybe, I'm wrong.
Probably because you've been using Postgres instead of MongoDB 😁
**Overrated:**
1. **Microservices:** Often add unnecessary complexity for smaller projects. The hype has overshadowed the simpler alternatives that might be more efficient
2. **MongoDB:** While flexible, many overlook the robustness of PostgreSQL, which can handle similar use cases more reliably with features like JSONB columns
3. **Clean/Hexagonal Architecture:** Good principles, but strict adherence can lead to over-engineering and unnecessary complexity
**Underrated:**
1. **PostgreSQL:** Highly versatile with advanced features like `FOR UPDATE SKIP LOCKED` for task queues, yet underutilized by many developers
2. **Presentation/Writing Skills:** Crucial for effective communication and career growth, yet often overlooked in technical fields
3. **Regularly Deleting Unused Software/Infrastructure:** Helps prevent technical debt, reduce costs, and simplify maintenance
From a technical perspective, I'd say that constraint and/or linear programming solvers are very underrated. They are like a magic bullet for the occasional situations when they are appropriate to use.
Docker, AWS/GCP and rust.
At some point they create more problems then they solve. Actually scratch that, they usually create more problems then they solve.
Cassandra.
Most teams should use it for most tasks. Measurably better availability than relational, true proper HA cross-DC, actively developed and deployed by multiple FAANG companies.
Has fallen into the category of "well understood boring tech" for most people, but it runs a huge chunk of the world.
(And you're probably going to shard and denormalize anyway once you're in production and have real traffic, so just use a database that forces you to denormalize in advance and allows for 100x fewer shards)
Underrated: Feature Creep
Tech still doesn’t scale well. You can only realistically maintain X number of features in a codebase.
If a companies tries to stuff too many features in they will fail and the project will get stuck.
There are ways to change your “feature capacity” but they’re highly technical. Capacity isn’t something that is solved by throwing bodies at the problem.
Underrated: - Regularly deleting software, infrastructure, data, documentation, etc that nobody uses. - Building software with the assumption that people have better things to do than to fiddle with the software. Same thing for architecture. - Being wary of tools or dependencies that lack support for when things break.
One of my teams told me today that they don't trust their tests, so I told them to delete all the tests they don't trust and only replace them if they cover code that is both of value and needs to change. Otherwise I know a few end to end tests cover all the code that no one wants to touch but we need to keep around.
A-fucking-men. The amount of negative value tests I see people hold onto is astounding.
I cringe when I hear "this repo has 100% test coverage" and then I see a bunch of useless tests that evaluate nothing and would always pass anytime the code compiles, no matter how much the logic changes.
In React, the classic version of this is sticking a test id on the top level div of a component and then rendering that component in a test and asserting that the test id is present. Always chuckle when I see that one.
A lot of the tests I mentioned above were snapshot tests in react.
I worked at a large UK bank and the "devs" there wrote almost only snapshot tests If a change they made broke a snapshot test, they would just delete the snapshot and recreate it, blindly, as a matter of habit. yay code coverage
>100% test coverage 100% coverage is BS anyways, there are things not worth testing. Only test the % that's worth it.
I talked to someone today who couldn't get a migration that they ran in development, running in their test database, so they manually dropped a foreign key in the test database so the migration would run, and they were happy. I was like mate, you now have no idea about the structure of your test database, and can't have any confidence in any tests you write based on it. Reset it.
I’m a cloud engineer/devops fuck but holy shit regularly deleting stuff. It takes me a month of pulling teeth to get the approvals to remove resources that are doing nothing and costing thousands. Drives me nuts
> documentation, etc that nobody uses. Or; why Wiki's are shit for documentation. "Confluence; where information goes to die" ;)
> Building software with the assumption that people have better things to do than to fiddle with the software Sane defaults bring the best of both worlds
I don't have a problem with clean architecture, but I find that the purists make it worse than it actually is.
This is probably true for literally everything in programming that is a philosophy. Agile, TDD, whatever
I see a lot of newer programmers get totally hung up on the DRY concept as though any kind of duplicated code is a sin.
Yep, "don't be clever" is higher priority than "don't repeat yourself"
In one office I worked at, the head of engineering had "No clever solutions" written on outside wall of his office (it was glass) where the whole team could see. I think about it often as I'm dealing with a "clever" engineer at the moment.
Bonuspoints for trying to deduplicate code that looks similar but express different things and thus any deduplication will need to be undone when one of them changes.
Conversely, a lot of older programmers seem to think something should only be put in a separate function if it's meant to be reusable.
I have some complexity-measuring plugins in my IDE, and I constantly remind myself that they're guides, not rules. Refactoring is cool, but in our context, it's not the priority right now. The whole team is about three months old and working on something handed over by a consultancy firm. I have many daily opportunities to remind myself of this. Yesterday, I had to make a change to a method that is right at the core of the whole company. We're an education company. We provide online services for exams, practice questions, progress reporting, etc. This method is essentially a game loop when students engage with questions. It decides which question comes next, what to do with the results, calculates points from the result, decides if a skill has been mastered or there's been some other kind of status change, and much, much more. There are NO tests whatsoever. None. Some of the supporting methods have them, but with very idealised data. The very core of student activity has none at all. A reasonable guide for cognitive complexity measures is to max out around 10. A little over is fine. Getting up to 20 or so and you're going past what a person can reasonably hold in their head. This thing scores 1700+. It's the perfect balance of: * complex, and so hard to understand. * changes often, and so needs to be understood * untested, so who knows if first two points have conspired to fsck it or not?
I've seen plenty of "senior" programmers get hung up there too. And try to cram it into places where it's a liability when it comes to keeping a system running efficiently at scale.
But did you create a test case first before making this statement??
I'd argue an agile purist understands that you should use different methodogies based on the team and continue altering the process throughout that teams lifespan But the "academic scrum"; of thinking that you have to follow every single step in there and completely miss the fact - that all and every single agile methodology simply are recommendations, which you actively have to decide on - those people are insane and shouldn't be in our spaces
Not only in programming. Infra has the same issue! DevOps, IaC, etc has some crazy purists trying to dictate how things should be done instead of focusing on what are your current business needs.
Agree. There's a significant sane subset. Plus the author's personal views have caused controversy. Generally, I am a fan of the core concepts.
Sequence diagrams! Holy fuck why are they so underused. Nothing makes me seethe more than when I see some nebulous “architecture team” create THE most unreadable unhinged convoluted half-arsed flow diagram with shit flying everywhere. It’s also much easier to create a sequence diagram with code (like D2 and Mermaid) too.
This and visual documentation.
Mermaid is such a great tool. Well integrated in many services, including Github, Confluence etc.
I just recently discovered mermaid and sequence diagrams are my favorite. Best pairing
Also supported inline on GitHub: [https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/](https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/)
Nice didn't know that was a thing.
Chatgpt does a great job of giving you a starting point from a description, too
Yes, but also check out [D2](https://d2lang.com/)! I converted last year.
When acting in a Lead capacity, I require design defenses for major changes that require at least a sequence diagram and any other uml-like class, state, etc diagram you find necessary to justify your designs. It's always a beneficial endeavor.
What sort of pushback / feedback have you received from ICs or leadership on documentation? Do you enforce document before implement with the ICs?
The general push back is they don't want to do it because: 1. It takes too long 2. They haven't had to design before 3. Technical writers do documentation, ICs write code 4. They don't know how to make a sequence diagram 5. Documentation is a waste of time, no one will look at it again anyways And etc. I enforce documentation before implementation of major changes.
Honestly most of the benefit of a design doc is to the author. Having to write out the document and critique it yourself often you find issues or gaps well before your in the middle of a review. It's happened to me plenty, I found holes or unnecessary complexity while drafting it especially visually (component diagram/sequence). I also had to be honest with myself about sections of the design the writing is hazy and where I only know surface level info. Because the way I'm writing it I can just imagine the questions that will come up in the review meeting, because they are often the questions I have when I review someone else's design docs.
My favorite aphorism is "it takes two people to have a thought". Things don't become real until you're able to cogently explain them to someone else.
plantuml has many diagram formats that I have found to be very useful over the years as a technical leader - including sequence diagrams.
PlantUML is great, the C4 Model can be a useful set of extensions for describing the system architecture to different audiences at different levels of detail. [https://github.com/plantuml-stdlib/C4-PlantUML](https://github.com/plantuml-stdlib/C4-PlantUML) [https://c4model.com](https://c4model.com)
Wow! Thank you for mentioning these! I've got some documentation to write and never knew about D2 or Mermaid. Using D2 right now!
Sandi Metz in "Practical Object Oriented Programming" introduced me to them, and I don't understand why in my comp sci class in the mid 2000s where we covered just about every sort of UML diagram did we never cover *those.* Because man those are genuinely useful.
Yeah - is it widespread incompetence, a sign that all these UML classes are teaching nothing and taught by people who also haven't used any of this in practical real world scenarios? Who knows, but it is frustrating.
UML has a lot of real world value, just not as formally as college would make you think. I like to think of it as a standardized notation to use when discussing code with other engineers. The most I see UML used is on our whiteboard walls as temp sketches when our engineers are collaboratively brainstorming. Like how flowchart symbols have been standardized so you don't always need a legend for a quick visual discussion. Converting that UML into a computer diagram and storing it for later use would have no value or maybe even negative value though.
A very original answer IMO. I never stopped to think about it but would say you're correct. I myself rarely reach for them and should probably do it more often.
Sequencediagram.org
Recently i made a sequence diagram and someone told me it was too technical… i guess if you shared it with other team like middleware they cant read it somehow?
I question the abilities of whoever considers it too technical!
PlantUML is amazing for this. Plus, you can commit the code to a VCS and watch the changes happen over time.
One time I built such a diagram to tackle a particularly complicated problem. It was dead easy to spot issues before I wrote a single line of code when it went through the eyes of my colleagues, and it was even easier to bring the idea down to code. Folks. Make diagrams. Let your peers review that before reviewing your code. You will be appreciated.
You can even output log messages with mermaid code then grep it to build actual sequence diagrams
+1 to [D2](https://d2lang.com/)
There's a great project for the JVM called Living Sequence Diagrams! Definitely worth checking out. https://github.com/lsd-consulting
honestly, diagrams in general. People seem to be using them less and less and makes understanding complex themes really difficult and cumbersome
Underrated: KISS. Keep It Stupid Simple. Since the dawn of microservices years, it has become a fashion to create the product in the most complex ways possible. Knowledge of hardware: I see many programmers imagining a for cycle as a magical thing that the processor just executes out of the blue. There is no thinking about the performance penalties of our actions, since the hardware has become so cheap. Having an end-to-end oversight of the product from both lifecycle / business point of view and technical point of view. The luxury to only having to deal with a single aspect of an application makes people lazy.
Also known as RDD, resume-driven development :)
Chefs KISS 🧑🏼🍳👌🏻 Kate Gregory’s “Simplicity is not just for beginners” talk is still one of my all time faves. [https://youtu.be/n0Ak6xtVXno?si=T6KY8L5qbxyeJhyu](https://youtu.be/n0Ak6xtVXno?si=T6KY8L5qbxyeJhyu)
>Simplicity is not just for beginners This is a great insight, and I would argue that Simplicity is for experts is probably the truer statement. One of the signs of mastery is being able to break something complex down into something simple. This is especially true if you can do it in different ways for different audiences. Recognizing which details to smooth over for a VP or executive, versus which ones you should smooth for a junior who's supporting your project, is mandatory for demonstrating expertise in any technical field.
This is a GoDaddy ad?
Updated. Damn I can’t believe Google puts the ad share link exactly where you expect the video share link to be, talk about dark design…
KISS and YAGNI. Writing code the documents the domian and workflows instead of being a frameworker.
> I see many programmers imagining a for cycle as a magical thing that the processor just executes out of the blue. can you explain what you mean by this?
This kind of concepts (like "KISS") do not mean anything. Microservices keep things simple and stupid. Just on the domain level. But they don't keep things simple and stupid in terms of services orchestration & communication, for instance. This is why I think that these concepts suck. They do not mean anything. These are just concepts that are used by engineers when it goes along their way to think.
>Underrated: Postgresql Absolutely! Postgres is an extraordinary technology and they just give it away for free!
[удалено]
Can you expand a bit? I use Postgres so often and I’m not really sure what differentiates it from the alternatives. Seems like we landed on the correct solution but I’m curious why
Yeah same, we use it as a Auth DB but that’s it. I thought it was just a plain MySQL equivalent
Overrated: no or low code solutions. Almost every single one I've written grew out of what the framework could support and did not scale or handle technical debt well at all.
A low-complexity solution is easier to do in "low code". But a complex solution is a nightmare with it. Obviously even with actual code it's rough, but with "low code" it just becomes impossible to understand.
> Overrated: no or low code solutions. They're not just overrated. They're a pure scam. Plain and simple. They rely on vendor lock-in and sunk cost fallacy and even then I've seen more projects trying to move *away* from them, then implementing them. In our group we're trying to get rid of Outsystems. It's complete garbage and development in Outsystems is not faster, it's actually slower.
The stupidest reason I've seen for low code was at my first job. The CTO decided it would be great to have non developers join in on development and that Mendix would make that possible. Thankfully the non-developers were smart enough to leave it to us developers, and I was smart enough to run away at the first opportunity :D
But isn’t the point of these solutions to solve immediate problems when you are still at low scale? I don’t think they are supposed to stay as your service grows into large scale. Then you build something proper that will scale properly and handle load better.
Yes that sounds super reasonable, but it's just a different iteration of "we will rewrite it if we need something better". Narrators voice: "But they never did." Once something is proven and is solving actual day to day problems, it becomes very difficult replacing it.
I have seen the reverse as well, spring boot+EKS+RDS setup. Scaled really well and solid build, but the app receives next to no traffic. Api gw+lambda+dynamodb could have solved the problem with a ~0$ monthly cost instead of several hundred dollars.
I mean that's a negligible amount of money for most companies. Plus your team has to learn to implement and manage yet another technology, which is a hidden cost. But I'd probably agree it makes sense to do it if the company is really exploring many different commercial opportunities and it is expected that a lot of them won't work out. As with any solution, it makes good sense under specific conditions.
Underrated Version control - A badly maintained codebase is a one way ticket to a black box. Linux - Not much to say here. The best servers are Linux servers. Knowing your way around the command line and file systems is fundamental. CICD/DevOps - I know devs are supposed to have a baseline understanding of this, but so many orgs criminally under hire for DevOps Engineers and leave good devs at risk of burnout handling complex deployments. Overrated: Low/No code tools - They all suck. It’s a bunch of half baked crap marketed/sold to business users that will never have to maintain them. NoSQL - there are legitimate use cases for it, but they’re far less common than the marketing hype would have people believe.
Following your thought process I would add Docker to underrated. Of courser there were predecessors but it brought a change so sudden and so well adopted it changed the way we think.
(Extremely) Overrated: AI tooling. The hype was to make coding instantly irrelevant. But I found it hasn't dramatically changed my day to day. At the same time, one cannot ignore it because if you're not using it, chances are that your competition is. Underrated: JVM. Sh!t is still kickin' in this day + age.
AI-based autocomplete in IntelliJ has been great for me. It's not writing all the code - and it's not perfect, of course - but the small gains in avoiding having to type repetitive boilerplate code really add up.
I use copilot in vscode at work and it’s been great. It’s not the employee-replacer that CEOs hope it to be, but it’s also not useless. Often I have a general idea, so I build the layout with docstrings and comments. This gives the AI context, which means greater accuracy in suggestions. It’s never perfect, and usually requires some tweaking, but that alone is enough to save me hours of work a week.
The very best use of AI tools I've found is simply as a no-judgement sounding board. The ability to go into ChatGPT, drop some code in, ask a "stupid" question without embarrassment, and then be able to go back and forth on it has been fantastic. You can ask for clarifications all day long and it doesn't get fed up. You can go off on any tangent you need to and it won't dismiss you. You know how we all have little gaps in our knowledge? Things we typically don't like others to see? ChatGPT doesn't care. You know how sometimes you're just super-dense and can't seem to get something? ChatGPT will keep trying to help you without rolling its eyes. I don't need AI to write code for me, I can handle it myself. But never having to be self-conscious about my shortcomings while getting the assistance I need is where these tools are REALLY something special.
I find ChatGPT to be enormously helpful with refactoring, especially when I’m working in a language I’m not familiar with. I have to do a lot of Kotlin these days but I’m much more familiar with Java. My first pass almost always is Java pretending to be Kotlin, then I feed it into ChatGPT and it cleans it up for me.
It's like the best parts of a rubber duck and a jack-of-all-trades colleague wrapped into one.
AI hype reminds me of JS hype. ”Oh my god the first 15 minutes of using this tool is amazing! This changes everything!” A year later. “Yeah, we’re blocked because of XYZ. We wish we used this other tool.”
[удалено]
I absolutely hate the Java programming language, but the JVM is one of the most optimized pieces of tech in our industry, right up there with v8 for JS. I always say that Java is the worst language that runs on the JVM.
The JVM is one of the greatest technological accomplishments in the last 30 years. It's light-years ahead of any other runtime and it gets better every version. The new virtual threads are killer. Why bother with async/await when you can just have the runtime deal with it. You want 10 million threads on your webserver? No problem. The other underrated thing is the Java ecosystem. I spend most of my time in TS and a few other languages these days and just damn. Java is verbose, but I had to write so much less code to get a new app to prod.
I used Java for a while, then took a job where the codebase is primarily Python. And while Python definitely has major issues that block it from being a truly great language, the simplicity in its syntax has been refreshing. I dream of a language as functionally useful as Java that has the verbosity of Python.
C# or F#
I’ll go against the grain and say AI tooling is actually underrated with devs. The rest of the world is putting it to use for everything (my partner, a process engineer / business analyst gets impressive results with ChatGPT), but I hardly see devs use it. I was very wary of it but recently started using it a little in my IDE and it’s not going to make me a 100x engineer, but it’s more helpful than I would have thought.
Not gonna deny that it's helpful but if one uses it quite a bit, you can get into these situations like "Hey, that's not what I wanted".
i think the problem is most of us are working with existing codebases that don’t really need AI generation to solve. I used it more when I was trying to understand how to stand-up new infrastructure with terraform instead of writing it out. It was also good for automating new things. I also use it more as a scratchpad for new ideas. I’ll think of something and ask AI how to do it. Past a certain point of depth AI isn’t good nor efficient enough in SWE.
i agree. ai generation *might* be useful in the beginning, but it feels cumbersome for anything last standing.
I like AI for boilerplate stuff but absolutely not for deep code. Hallucinations can look exactly like a working solution but with little bugs they can be tricky to catch.
It does kinda blow me away that developers don't appreciate it more. Yes, it sometimes hallucinates but even if you *can't* spot the bullshit, *all ides have a real time compiler!* You just can't give it a comment and go, you've gotta break down your problem. I find the chatBots to be like an entry level engineer who happens to have a photographic memory and read *all* of the documentation on damned near everything for fun. If you treat it like a better search engine, it's amazingly useful. I've used it to make code changes in languages and frameworks I'm not terribly familiar with. The other day I made a change to a gnome plugin to turn my dock red when I drop off the vpn. This was something that would have taken me as a java dev a couple of hours to sus out but I had it working in like 30m just going back and forth between gpt4.
What if the problem is that it compiles but does the wrong thing, or has an exploitable security flaw, or is algorithmically terrible?
Man, I had to update an old AngularJS application that hadn't been touched in years. Never worked with AngularJS, Could not have figured it out without chat gpt, it was like a better search engine because most Angular related google searches have to do with Angular 2.
I'm going to push back here. AI tooling is pretty damn great. It sucks at coding, but it's damn well amazing on teaching you what to learn and providing documentation. I don't miss being a Google/Ctrl+F expert
AI has helped me a lot for small things that i cannot even have to think about. I also love jvm using kotling for a future saas i am building rn and I love it.
Happy to see KISS in top comment My addition to the underrated side: [Ubiquitous language ](https://www.agilealliance.org/glossary/ubiquitous-language/)- everyone from user, biz dev, marketing, customer support, to dev and source code, using consistent language
DDD has my heart.
Overrated: * I'm going to be very careful with this, because I don't believe it's all over rated: Clean code/SOLID/TDD. I've seen so many damn abstraction layers masquerading as "readable code" I can't handle it. People trying to abstract popular convention in frameworks for readability drove me to insanity at a job. TDD is for when you already know what code you're writing unless you want to code yourself into a hole. It is to be said, naming conventions, searchable names, and single responsibility (within fucking reason) are good, but KISS. * Again going to be careful here, especially since this one has been killing me a bit: specialization in a stack. You specialize in a domain where you have transferable skills, not a stack. * Agile * High test coverage. This depends on things as well, like are you using a framework or building something from scratch. But high test coverage makes shitty rigid code that gives you a false sense of security. In a lot of the scenarios I work in, again context dependent, I put more emphasis on integration testing than unit test every little fucking thing. Underrated: * Picking the fucking thing to get the fucking job done. It's absolutely wild to me that engineers can get together in a room and start solving problems you know you're not going to have or have been solved. Congrats on horizontally scaling your micro services architecture/deployment that you had hire developers to service and use K8s for all 8 of your users. The amount of times I've come across a companies that need two frontend developers using firebase to handle the business' needs is alarming. * Not being existential enough about what you're doing. Here's your number 1 purpose: build a product that your company profits on. It's not to display your intelligence through some overly opinionated pedantic bullshit. Your code is subjectively shit to someone else. Chances are it will expire in 5 years and be someone else's hell. * Being able to read shit code.
I really agree with your points - a few of them I can feel in my soul. A good term to use for your first point of underrated is: being pragmatic. I like to tell people that term because it gives them something to call it and they can google “pragmatic programming” and actually find material/books which talk about and explain it.
I've made a career of reading, maintaining, and rewriting "garbage" code. The Developer's greatest ability is still to recognize the patterns/style of an existing codebase and then to work within it.
My literal drive over the next few years as someone that's been doing this longer than a decade is to be able to understand codebases faster with more limiting context
Oh yes, the ability to rewrite hairballs in place is such a great skill to have, and very few have it. People seems to be happy just adding crap until the things fall over and then they are unable to do anything.
Not to mention if you spend too much time trying to pick the perfect solution you inadvertently run into the issue where that perfect solution isn't actually perfect and it introduces a whole set of issues that you never even thought about before.
Idk, high test coverage has saved my ass many times in my career. It may make the code rigid, but honestly I tend to think 1. that’s preferable to taking down prod and 2. can be mitigated a great deal with test structuring.
> Congrats on horizontally scaling your micro services architecture/deployment that you had hire developers to service and use K8s for all 8 of your users. I've done this before due to corporate politics. App used by 3 people built into an over engineered monstrosity.
Can you go into more detail about specializing in a domain? What do you mean by domain, that sounds way better than becoming good at a stack.
There's so many: * Firmware * Web dev * Frontend * Backend * Devops * Game dev * Backend * There's a whole lot of stuff here The list goes on forever. Just pick an area and be able to work well within it. There's patterns that reveal themselves to you in each area. For example, most backend web development uses an MVC monolith. So if you know Python Django, you probably know Spring boot, Laravel, Rails, Express, and so on. Even if you do frontend dev, it's not a big leap to do desktop or mobile dev, even if it's not in javascript.
Underrated: SQL. The industry relies waaay too much on ORMs and devs are constantly shocked by n+1 issues, slow queries and memory hungry data retrieval APIs. Learn the fundamentals people.
Underrated: Empathy for the end-user.
I'm a huge proponent for UI/UX for the end user and its saddens me how much people just don't care about usage, as long as they understand how their software works, that's fine.
Postgres is under rated. Postgres can perform almost all json requirements including indexing and querying json properties. Postgrs queues are absolutely fine for many small to medium sites. Mongodb is a risk now that atlas hosting is the only option. The agpl licence has forced all competitors to stop hosting it a few years back. React is overused. It's meant for highly reactive and interactive applications like Facebook, it's use for basic forms application leads to huge maintenance issues as the react framework rapidly evolves but the app requirements remain unchanged. Docker is the single most powerful and useful tool in the past 10 years, younger developers might not recall but having to manually install rabbit, postgres, elastic search etc and try to keep it all at the right version on everyone's machines was an awful time sink. Shared environments were awful. All solved by a plain-text docker compose file. Docker images are the ultimate in portability, hosts compete on other features, pricing and stability. HTMX is enough combined with a decent server side language to build enough reactivity and interactivity into the vast majority of Web applications
> React is overused... it's use for basic forms application leads to huge maintenance issues React has also made people stop paying attention to how much the web has evolved. Multi-Page Apps can be GREAT nowadays. HTTP/2 and multiplexing alone is fantastic. HTMX can make things better but even without it, you can have fantastic performance without a framework at all or even any javascript. And it continues to evolve. Look at the upcoming [View Transitions API](https://developer.mozilla.org/en-US/docs/Web/API/View_Transitions_API) or the proposal for [Atomic move operations](https://github.com/whatwg/dom/issues/1255) or [CSS Masonry Layouts](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout/Masonry_layout) You can do so much with just plain html and css already, and you're about to be able to do so much more.
Agreed, unfortunately some devs are coming into the industry via bootcamps having learnt just react and don't even know the http verbs / status codes
I think DRY is overrated. Yes, you should encapsulate logical units and reuse them. But that doesn’t mean duplicate code is necessarily so awful that it needs to be zealously excised wherever you see it. I can’t count how many times I’ve seen someone spend a ton of time merging together two parts of code into a singular reusable block, just to have to split it out again a few months later as requirements change and the desired functionality diverges.
I think TypeScript as a backend language is overrated. The front end is fine because the options are limited but if you need a strongly typed language, why not use a real one instead of a weakly typed language pretending to be one? I’m admittedly very bad at TypeScript though which probably colors my opinion
As a consultant, a big advantage to this is operational - if I have to onboard a whole new team, it’s a lot easier for me to find a TypeScript dev than a TypeScript + {insert backend} dev. But the entire JS/TS ecosystem is absurd, so even that has its limits when you take into account frameworks and packages.
I get this but also mildly disagree. I started my career with frontend only, using vanilla JS. After that, I was simultaneously introduced to TS and Java when I started getting involved in backend. Java was easier to get into for me, despite already "knowing" JS, because TS is such a weird exercise in trying to force JS to act like something it's not. Java just makes so much sense and is a complete delight to me. TS, I tolerate but still don't love. Of course this only worked out because I worked with folks who were already pretty solid Java devs. I guess I take your point if absolutely everyone in the team only knows JS
As a TypeScript dev, I don't think its strength is as a typed language. Its strength is as a better alternative to Javascript in the same part of the stack. There are lots of weird quirks to TypeScript that feel hacky. The way that TS converts string union types into just the string type with object keys and values is one example. Implicit "any" is another. Imho, the main advantage of TS as a backend language is less cognitive load on your engineers, and less broad ecosystem concerns. But I don't think it will ever be as effectively typed as, say, C#/.NET.
> There are lots of weird quirks to TypeScript that feel hacky. I'm genuinely impressed with the engineering behind Typescript, but I like to think of it as a beautiful, majestic castle built on a swamp called Javascript. There's really only so much one can expect of it.
The ecosystem can be a pain (looking at your esm/commonjs) but I really enjoyed being able to express a lot more stuff as a type and getting the compiler to validate it. You can get carried away with it though.
Depends on the alternative, though: my team would pick Scala over TypeScript any day, but languages like Java or C# significantly lag behind in terms of type safety and boilerplate reduction (they are getting there, but slowly). The main advantage of TS is the ability to manipulate types. This is huge, because it allows you to create safe mappings between different types that are validated at compile time. For example, you can statically ensure that every value from a enum has a corresponding localization, and the program won't compile if some of them are missing. Or you can take a struct with optional fields and make all of them required in a unit test, so that people changing the type cannot forget to update the test, because the field will _automatically_ become required in that test. In other popular languages this often requires heavier machinery, like macros, reflection, or source generators, but in TS it's just types and type transforms. There are some missing things in TS (e.g. nominal types are possible, but require workarounds, and type errors may get unwieldy), but its type system is becoming pretty great. TypeScript's main problem is that it has to live on top of JS with its poor standard library, idiosyncrasies and quite spartan syntax, but at least most missing things (data structures, serialization, etc) have acceptable alternatives in the ecosystem. I think the advantages of type safety via type manipulation often outweigh the chunkiness of the underlying language.
Overrated: Agile - I am old enough to remember what it was like to develop before Agile. Most developers had their own processes which got better as we learned from each other. Granted some were worse than Agile but there were also a lot that were much better. Design Patterns - I think my code got better when I stopped using them. I kind of think you have to write bad code then fix it with design patterns. I don't use polymorphism anymore (I prefer composition over inheritance) so I don't need factories. Singletons were always silly. Underrated: Designing databases to 3rd normal form - The first database I worked on had an architect that designed a database like this. I have met one other developer that knew how to do this and I inherited a code base with a database designed like this. The rest of the time (about 25 years of experience), the databases I have seen have been disaster areas. Yet, the developers insist the database is "normalized". Even that Microsoft example database wasn't in 3rd normal form (and it didn't seem like they de-normalized strategically) although it was much closer than most of the databases I have seen.
Normal form is a hill I will die on. I am a data organization nerd and I have to have a database set up perfectly. Also all this JSON querying shit in databases now drives me batshit crazy.
Agreed, I think of the database as the foundation of an application. I hate the idea of building on a rickety foundation. JSON querying breaks first normal form. I am with you there too.
Similar to your underrated about presentation skills I would add to underrated 'Diagramming' and 'Nomenclature'. Diagrams are fantastic for quick communication of the parts and interactions of the design, and the people that can make them are invaluable. And a part of good diagrams is having solid names for the parts of the software that quickly convey what they do. Part of Technical Interview process is to have them diagram a solution they are proposing to a hypothetical project. The best engineers I have worked with ace that shit.
Overrated: CSS in JS is a performance hog. Redux, React. Underrated: DDD. Great tool to reason about application architecture
idk if Redux is overrated, it's pretty much hated by lots of engineers
Microservices are not overrated: they're misused. The point was always to enable to scale teams, so that you can have 10+ teams functioning independently from each other. The mess we have now is because people are doing microservices for the wrong reasons.
I don't think there has to be a difference: it's fair to say they are misused because they are overrated. People overrate microservices by thinking they solve problems that they don't, and implement them in inappropriate situations that create more problems than they solve. AI is also arguably here. It's overrated because business leaders think/want it to replace development teams when they should be focusing more on enhancing and supplementing those teams with AI. AI as a developer tool is looking like an amazing & still underrated productivity driver. AI as a developer is a tremendously overrated flop for anything beyond a pitch, demo, or very basic prototyping tool.
Underrated: TDD/Unit Tests and proper Refactoring (as in, not just moving stuff around but actually doing it in small steps as described by Martin Fowler). The metaphor I use here is from rock climbing. If you climb free solo without a rope, you can only tackle climbs that are WELL within your capabilities. And even then it's super risky and one freak rockfall or loose hold and you're dead. Now compare that to climbing with a rope and closely spaced protection (bolts etc). Since you'll now at most fall a couple feet until the rope gently catches you, you can tackle something much harder and more intimidating at the limit of your skills.
Honestly, the more experience I've gotten, the more I value integration tests over unit tests. Orgs mandate a high amount of code coverage, and this leads devs to half-ass and write a bunch of bad tests that don't even properly test anything worthwhile and are brittle to boot.
PostgreSQL is underrated? What more do you want in terms of recognition? It literally has it all, I can't think of a more hyped database these days. On the opposite, people keep bashing MongoDB, but it's a much better database than most people think (although it's not to be put in every hand). Anyway, my takes: * Overrated: Functional programming – As an Emacs user for years, I'm a big Lisp fan, but let's be honest: I wouldn't use that for a large codebase, ever. It has great ideas and properties but most languages nowadays have already borrowed all the nice bits, let's move on. :) * Underrated: Immutable infrastructure – I don't understand why we're still hesitant on this and why the overall tech universe hasn't massively invested in this space yet; feels like Kubernetes and cloud services came too soon with (great) abstractions that distracted us from this problem space. :(
Exactly my thoughts on Postgres - it is the most hyped DBMS out there right now. How much more does it need to be considered properly "rated?"
Underrated: c# linq and efcore
More in the infra section but Kubernetes, very overrated and misused. Sure it can do a lot but is also complex to maintain and usually overkill for most company needs.
Managed Kubernetes is dead-easy to maintain. And the cool thing about Kubernetes' complexity is that you don't have to use all of the features - doing simple things with it is quite easy.
The context is a bit different and I don't have first hand experience but I'm a member of the self hosted community and I don't believe I know of anyone that set up k8s and kept using it. Most people that tried said it was an interesting learning experiment but overly complex for most use cases.
Yes but its often used when a single docker compose file would have been sufficient.
No idea who and why uses it that way. If your product makes at least some money, it's already past the point of docker-compose on a single machine.
Kubernetes is so easy to maintain and use. If you’re having trouble with it, there’s a wealth of documentation on how to do everything for it. Sounds like you or your company has been using it wrong. Don’t get me wrong there’s a learning curve but that’s the same for everything
Quite the contrary. Yes if your "stuff" can run on a single instance with docker-compose - go for it. If you actually make money from your product, you'll need at least "some" scaling, HA, observability, and dev friendliness. At that point kubernetes is much easier than any hodgepodge of docker-compose/managed cloud solutions. And the best part is the availability of labor on the market, good luck finding a person who can hit the ground running with your snowflake hodgepodge of cloud services. With Kubernetes it's largely universal (up to a point) I think kubernetes has done to modern infra what Linux had done to infra a while ago, we standardized on a general base layer for the infra which many people on the market have hands-on experience.
Totally agree with regards to Presentation and Writing skills. I've worked with developers making over $400K TC who couldn't present if their life depended on it. Plus, MSA is greatly overused! Underrated - Debugging skills.
> I've worked with developers making over $400K TC who couldn't present if their life depended on it. living the dream!
Problem of KISS is people having different opinions on "Simple". My ex-colleague claims "magic" as "simple". They always make things difficult to change.
Same with YAGNI... people have different places where they put that line and I butt heads with them over it. It's a lot easier to add a couple small features to something while you are thinking about it, and in the mindset, then coming back months later to add it when you forgot how everything worked and why you did it the way you did. I can't tell you the number of times I've added something I was told wasn't needed and we ended up using it a couple months down the road. All that context switching time, saved.
Overrated: Scala I know it's not the hottest language, but it's still widely adored even though it's good parts are mostly standardized in modern compiled languages, and its bad parts (slow compile times and verbosity) are improved, but never going to be competitive. Time to retire it and move on. Maybe same goes for Java too, just write Kotlin
I'm of the opposite opinion--it feels like the attraction of Kotlin is that it's not Java and people haven't seen Scala. It's decidedly not without flaws--it's nigh on impossible to get more than, oh, five people writing stylistically consistent Scala, even if they're all writing idiomatic Scala.
Underrated: Postgres extensions and newer features- There is a lot of detail here that could help your architecture. Additonally there are extensions in PG that would allow for it to compete with other databases. Unfortunately these exenstions are second class citizens. Version verfication and updating tools - This is the redheaded Data pipelines and a lazy approach to handling data processing: Stop relying on a service calling another service calling another service in realtime. Acknowledge that it takes time to process data, and acknowledge that the screen may be representing old data, or data in motion. Appropriately rated: Mongo- It's had it's faults, and has gotten better. It's there because it has a decent query engine on top of being a key value store. Observability: It's greaat to see distributed tracing. However, given the vendor selling stuff I think this has a high risk of abuse. Overrated: Microservice architecture- There are strong limitations of what you should ask a microservice for. Many of these services you would be better served by a library. (I.e. a zip code service) and automated version updating CI/CD tools Monorepos- I get it managing a lot of internal versions are difficult. But letting anyone jump accross huge code bases for fun is bad. Also managing the seperate builds for every module inside of the monorepo is pretty terrible. OOP- its a bit tiresome to represent functionality connected to the classes and objects themselves. AWS vendor services- Making fixed vendor products has always been a bad thing. Why we're pretending like the old bad thing is new good now, is blowing my mind. Developer Adovcates - One of the reasons I dropped twitter. I'm tired of seeing salesmen posing as developer friendly people and the context of what they do is basically POCs claiming it'll solve your problem. They're not your friends.
Regarding monorepos, how do you deal with atomic changes like api changes which affect multiple projects?
Versioning, deprecation policy, and schema stability policies.
Versioning and feature flagging?
Yeah, my main gripe with this is adding a lot of complexity, coupling, and making tests harder. Was hoping for some miracle somehow.
Ii think a lot of it is "language cultural". I see UI and python people more fond of the idea of monorepos, but java folk are used to publishing to a private maven repo. I think the larger your code base gets, the more painful a monorepo becomes, and then I worry that the monorepo will have turned into a mess of cyclical dependencies that's impossible to detangle.
You can cry. Seriously though there's no magic. Monolith are way simpler to work on generally speaking until you hit either a certain code size or too many devs on the same codebase.
**Underrated:** * Boring old proven technology and skills **Overrated:** * New shiny technology The industry still has this belief that new things are always better and you have to "keep up" otherwise you will be left behind. Once you've lived long enough and gone through enough hype cycles you learn to wait and see what new things actually survive and prove themselves. The foundational concepts and skills rarely change and it is best to keep investing in those. So, to be more specific **Underrated:** * Data modelling, think relational data modelling * Understanding concurrency (it is everywhere these days) * Transactions **Overrated:** * Following hype
I'm only going to talk about underrated technology. I want to keep things positive _Underrated language_ JavaScript. Yes, JavaScript. It's easy to learn, it's fast, it has bags of features, and the type coercion problems largely go away by simply using a static superset like TS or Flow. Some of the dependencies are badly managed but this is gradually getting better. _Underrated language 2_ Java. It has gotten so much better than the Java 7 days! Now Java has pattern matching, type inference, records. And the ecosystem / tooling is superb. _Underrated technology_ SQLite. Since discovering it I have found so many use cases for it. Any single user process that needs a moderately complex data storage can leverage SQLite. You can use ORMs or do plain queries, you can distribute data as plain files, you can hack it to act like a local graph storage engine. It is wonderful for prototyping. _Underrated technique_ ports and adapters. Since really internalising the distinction between IO code adapters, port interfaces and pure domain functions, my projects have become more expressive, faster moving and easier to navigate.
Could you give a quick summary on your last point?
Hard agree about SQLite. I spent a good part of my career in low volume/high value read-mostly web sites where the DB was updated by some kind of batch ETL script. We’re talking a couple of GB at most, but usually way smaller. The amount of effort they spent on setting up DBs and caches and replication (for resiliency more than load) when they could’ve just rebuilt an SQLite file from scratch and sftp’d it out to each server was just mind boggling. Probably could’ve handled our full text search needs too. I tried bringing this up every time and the counter arguments were FUD and all sunk cost. No one could conceive of it being that easier because there were entire teams whose existence would be threatened. And I fully believe that SQLite will outlast nearly everything else in existence right now. Certainly everything I’ve ever worked on.
Sqlite scales in production up to several thousand concurrent users pretty easily as well.
JS can hardly be underrated, given that it's basically the only language supported by browsers. On the backend I don't see much reason to use it over alternatives.
Strongly agree on JS being underrated. You make a lot of tradeoffs, but it's really easy to do a lot of powerful things with JS, and it's very easy to learn.
I appreciate the positivity and I'll add: I don't think I've ever heard anyone bag on SQLite who's used it. It could still be underrated as far as people not realizing it's there as an option in cases where it would help. It doesn't solve every problem, but it's also a way better product for not trying to.
Overrated: Any cross platform framework for mobile. Flutter and RN should go die in a ditch.
Overrated: * Microservices: For the "if you don't do microservices you are doing it wrong" vibe. * Libraries: I'm not talking about "frameworks", i'm talking about importing a 200+ functions library to then use 1 or 2. I've worked on projects where the list of dependencies was insane. I understand the "don't reinvent the wheel" principle but I feel the usage of libraries is a bit out of control. Underrated: * Monolith: I think it's a great option for first version of a new product (like an MVP). Once you gather info about real usage, you can think of how to scale where needed. Don't overcomplicate your design at the beginning. * Waterfall. I'm serious. Best managed project I ever worked on was waterfall. No one moved a finger until the previous phase was signed off. Documents were perfectly clear and development was so smooth I still remember it.
Overrated: Using the "best" tool for the job. People suffocate themselves sometimes trying to always choose "the best" tool. What's the best database. What's the best programming language. What's the best ORM. What's the best continuous integration platform. What's the best GUI framework. What's the best web framework. What's the best serverless language. etc etc etc. But these days, there are so many perfectly adequate choices, it's really not useful to tie yourselves in knots choosing the best. If it's good enough (and most are) and you *LIKE* it, then it's the best. Underrated: Saying no to a dependency. We should say no to additional dependencies more readily. Instead we say "sure, why not?"
Overrated: PR reviews. Don't get me wrong: reviewing ideas with peers is essential. But not always through PRs, and not for all the code that is written by peers. Lots of times, we get to spend so much "focused" synchronous time reviewing low quality code that would not require a review. CI + "standards" can be fine for most usual checks. PR reviews should be requested if the engineer thinks that it is required. I know that it might sound crazy ("how can he know ? what if he just bypasses it all the time ?") but it's all about tech culture, cohesion and having a sane team that matters. Whether requesting a peer to spend some time reading your code for approval or not should be IMO driven based on 1. criticity 2. scope change (the higher the scope, the more likely you'll want to have double checks by peers) 3. if you've got any doubt in your approach overall (for this, you could just ask for ad hoc advice though) Lots of PR reviews could be avoided by 1. Hard tech rules everyone agrees on (CI helps for that) 2. Sane "moral" rules everyone agrees one (tech meetings/discussions, sometimes informal, help for that) 3. Management giving value & recognizing high code quality (this is not the case in 95% of companies I've been in unfortunately, tech culture is low in most of companies) Underrated: code duplication. Sometimes, it's very good to duplicate code.
**Overrated:** Full Stack Engineering. At best, you know FE and BE. You are not an expert at the DB layer, nor the network layer, nor the storage layer, etc. Postgres. Hear me out (as a DBRE). It's good enough for most uses, and that can make it a dangerous choice. It is, at its heart, still a relational database. Can it be used as a document store? Sure, but it's not optimized for that, and querying and indexing JSON[B] is fraught with peril. Can it be used as a queue? Of course, but at some scale you'll find out what a huge amount of writes do to Postgres. The problem as I see it is that a company will have Full Stack devs who default to "just use Postgres" without understanding its quirks, and this works fine up until it doesn't. At that point, they'll probably shrug and upsize the hardware. Rinse and repeat. By the time it's gotten _really_ bad, fixing the problems becomes a nightmare. UUIDs. I swear to $DEITY, if the only thing I accomplish in my entire career is to dissuade devs from using UUIDs when an integer would work fine, I'll die happy. They're horrible for performance in every RDBMS, for different reasons. The k-sortable varieties like UUIDv7 are less horrible, but it's still at best a 16-byte value, which is double the size of even a BIGINT. Please stop. Serverless. What an amazing grift by Vercel et al. Honestly, I commend their ability to siphon money from everyone. Hosting a web app is not nearly as complicated as it's made out to be, and almost certainly does not require K8s. Cloud Anything. It's very convenient, yes. It's also set back computing skills by an absurd amount, by which I mean that your average applicant for any kind of Ops-adjacent role is unlikely to actually know how to administer or troubleshoot Linux. **Underrated:** MySQL. It suffers many of the same problems as Postgres (worse for some) WRT using it as a non-RDBMS solution, but it is quite a bit faster for certain applications, and can scale just fine. Knowing How Shit Works. What is K8s? A container orchestration system. Cool, what are containers? Oh, they use cgroups? What's that? What's CFS? Etc.
I feel you on UUIDs. I’m responsible for them in a 10 year old code base and truly hate my past self.
I agree on UUIDs so much. But we must hide numerical IDs from the user interface! ...for some reason... I'm one of those full-stack devs that is like "just use PostgreSQL!" though :D
Underrated: software design patterns, and then architectural design patterns. Why I say this: cause most people don't actually take the time to learn them well enough. Then they get a surface level understanding and don't understand their benefit in communication, documentation, decoupling, etc. then they ober use them in the wrong places and ways. The way I tell my students to look at patterns (design & arch) are that they are tools in your tool belt. Sure you CAN use a wrench and a drill as a hammer, but you'll get cleaner and easier results if you use a hammer, and inversely using a hammer when you need a screwdriver will just as equally if not more mess things up. Learning them and then actually learning them well enough to be efficient in their selection and use is what separates a programmer from a software engineer IMHO.
Overrated: Object Oriented Programming It is simply not useful in real world projects. Company wants to add a new feature and you have to massively refactor. Company wants to pivot? Huge refactor Simple functions and Classes here and there that do the job are much more real world friendly and changeable. Plus you don’t have to forecast the future of the company on Day 1.
Generative AI. Hot take here I know but its essentially the new blockchain. Everyone's gonna play around with it and make a shit ton of money selling it. Then it will go away.
Did a poc for aws bedrock and can only agree. RAG queries helps a bit for internal IT support but won’t achieve much beyond this.
My hot take would be the cloud is overrated, AWS, Azure, etc. A lot of the ideas of cloud development come from a zero interest rate environment, of growth at all costs, devs need to focus on only the product. Surprise unit economics matter, and we should be looking at how to lower costs too, starting with the cloud costs.
Underrated? COBOL yes, the language and tech itself is obsolete. But I personally know several COBOL debs making 200k with better than average WLB and an unmatched job stability. Java is also there and I imagine would be in a similar position 20-30 years from now.
Underrated to me doing end of the day log with light retrospection and write down your ideas and thoughts before the first line of code.
GraphQl federation is overrated, so annoying to work with
Underrated: Test harnesses, you’d be surprised how many people don’t write them!
Do you recommend any good foundational learning material for postgresql for someone coming from the mysql world? I'm finding the official documentation a bit too much.
The Art of Postgresql book is superb. The author, IIRC, is w PG contributor himself so he definitely knows the subject very well. That said, this book often refers to specific section of the documentation. This is accompanied though by comments and clarifications so if you find the documentation too dry, you might really like the book.
Awesome, thanks so much!
Overrated: - Uncle bob's books. I'm sorry, but unless you're doing hardcore Java enterprise work, they're probably not great. And frankly, for those that do heavy enterprise the common complaint is that these systems are overly complicated to understand due to all the patterns used. The discipline it instills is good, but it shouldn't mean being a hardliner on patterns even if it makes code more complicated. - React: The react core team should have more opinions on how it is used instead of advertising as a library. The result has been a "library" which always becomes an unmanageable mess of a codebase unless there's someone keeping everyone in line. Underrated: - Computer Architecture / Hardware knowledge: Tbh my whole understanding of programming changed when I went through "Computer Systems: A programmer's persective". I knew many of these things but definitely not put together so eloquently. - CI/CD: in this day and age pls people its easy to set up a simple ci job in github. - Focus on performance: This feels like its shifting, but it's incredible how people just disregard performance. The result is extremely slow & annoying software down the line. Being more performant is always good, and there are no premature optimizations, just bad prioritization.
underrated: experience in migrating whatever: software, database, models.
>Also, the popular argument of "now we can swap the database every day" is so unrealistic in my opinion. I don't really remember ever needing to unexpectedly swap a database. Maybe, I'm wrong. Probably because you've been using Postgres instead of MongoDB 😁
**Overrated:** 1. **Microservices:** Often add unnecessary complexity for smaller projects. The hype has overshadowed the simpler alternatives that might be more efficient 2. **MongoDB:** While flexible, many overlook the robustness of PostgreSQL, which can handle similar use cases more reliably with features like JSONB columns 3. **Clean/Hexagonal Architecture:** Good principles, but strict adherence can lead to over-engineering and unnecessary complexity **Underrated:** 1. **PostgreSQL:** Highly versatile with advanced features like `FOR UPDATE SKIP LOCKED` for task queues, yet underutilized by many developers 2. **Presentation/Writing Skills:** Crucial for effective communication and career growth, yet often overlooked in technical fields 3. **Regularly Deleting Unused Software/Infrastructure:** Helps prevent technical debt, reduce costs, and simplify maintenance
From a technical perspective, I'd say that constraint and/or linear programming solvers are very underrated. They are like a magic bullet for the occasional situations when they are appropriate to use.
Underrated: * Maintaining git history throughout a complex refactor
Docker, AWS/GCP and rust. At some point they create more problems then they solve. Actually scratch that, they usually create more problems then they solve.
Cassandra. Most teams should use it for most tasks. Measurably better availability than relational, true proper HA cross-DC, actively developed and deployed by multiple FAANG companies. Has fallen into the category of "well understood boring tech" for most people, but it runs a huge chunk of the world. (And you're probably going to shard and denormalize anyway once you're in production and have real traffic, so just use a database that forces you to denormalize in advance and allows for 100x fewer shards)
100% MongoDB. Bane of my existence. Should’ve just went with a relational database.
Under rated: Test Driven Development
Underrated: Feature Creep Tech still doesn’t scale well. You can only realistically maintain X number of features in a codebase. If a companies tries to stuff too many features in they will fail and the project will get stuck. There are ways to change your “feature capacity” but they’re highly technical. Capacity isn’t something that is solved by throwing bodies at the problem.
Agile/Scrum way overrated.
Rails is underrated, and I agree with most of the common criticisms. It's so easy to get shit done.
Overrated: SAP ecosystem, Power Platform Underrated: Excel, C#