Earlier quoted context omitted.
As an engineer-turned-manager, I spend a lot of time asking engineers how we can simplify their ambitious plans. Often it’s as simple as asking “What would we give up by using a monolith here instead of microservices?” Forcing people to justify, out loud, why they want to use a specific technology or trendy design pattern is usually sufficient to scuttle complex plans. Frankly, many engineers want to use the latest t…
>Forcing people to justify, out loud, why they want to use a specific technology or trendy design pattern is usually sufficient to scuttle complex plans. Does that really work ? Usually these guys read the sales pitch from some credible source. Then you need to show them that the argument is X works really well for scenario Y but your scenario Z is not really similar to Y so reasons why X is good for Y don't really a…
Software engineering topics I changed my mind on
221–230 of 704 posts
Re: Software engineering topics I changed my mind on
#22211 years in and my one critique is: >Designing scalable systems when you don't need to makes you a bad engineer. You have to have a very good understanding of the 'need' ahead of time or you're effectively just playing a kind of lotto. Do the bare minimum and it meets the need, you win. Do the bare minimum and it doesn't, get ready to start over, you lose.
Re: Software engineering topics I changed my mind on
#223Earlier quoted context omitted.
Yep, there also exists such a thing as "I learned language X and will not use it for my paid work but it made me a better programmer". One such example for me is Racket.
For me that's been Elixir. It's made me appreciate some of the more functional aspects in Python, like generators, map, filter and the functools library in general.
But I fully get what you mean. Working with it and learning it has been a very strong eye-opening experience.
Re: Software engineering topics I changed my mind on
#224> In general, RDBMS > NoSql
I use NoSql because RDBMS is a premature optimization for me
My experience with ORMs especially ORMs I didnt chose is that they are frail, assume too much and I often end up writing my own plain text queries anyway, all so that I can get a result from the database in object form, but without bogging down the database with inefficient queries
NoSql is object and collection based by default, and any Orm-like necessity is standardized with that database, instead of with a third party under-maintained library
My projects dont need to brag in an engineering blog about scalable performance, and the memcache solves all bottlenecks I’ve ever encountered
Re: Software engineering topics I changed my mind on
#225According to the author, FP is another tool. No, Functional Programming is NOT a tool but a paradigm which is a formal system of computation based only on function called lambda calculus.
A programming paradigm, or in plain english: a way of thinking and stating solutions to problems, is just a tool. Just like OOP is just a tool and procedural is just a tool. I'm in the camp that FP should be the default tool for expressing business problems, jumping down to procedural or OOP for caring about some kinds of low-level details, but it does not make it anything other than "just a tool".
Re: Software engineering topics I changed my mind on
#226>Java isn't that terrible of a language. That is going to evolve in the next six years to "languages don't usually matter much except in specific domains in a few cases"
If someone says "language doesn't matter" it usually means they suffer from the blub paradoxon.
Re: Software engineering topics I changed my mind on
#227Earlier quoted context omitted.
A programming paradigm, or in plain english: a way of thinking and stating solutions to problems, is just a tool. Just like OOP is just a tool and procedural is just a tool. I'm in the camp that FP should be the default tool for expressing business problems, jumping down to procedural or OOP for caring about some kinds of low-level details, but it does not make it anything other than "just a tool".
Not sure if I follow you. I thought a tool != an abstraction According the English dictionary A paradigm is a standard, perspective, or set of ideas. A tool a piece of equipment == something is concrete Can a mathematical expression or equation be considered a tool?
Re: Software engineering topics I changed my mind on
#228Usually i disagree with these types of lists, but this one seems pretty spot on. My only quible would be that only code quality static analysis is useful. Security static analysis on the other hand (e.g. taint analysis to find security bugs like XSS) is pretty overrated most of the time unless you work really hard to make it fit in your context. I also think linting rules are important, not for what they actually do,…
> I also think linting rules are important, not for what they actually do, but just to get everyone to stfu about variations in code style that dont matter and arguing about more important things. Agree. I don't think that there's one "best" style, but I've worked with people who don't care about consistency at all, and their code is so much harder to read. There's bunch of value in just picking a style and sticking…
"Gofmt's style is no one's favorite, yet gofmt is everyone's favorite."
Re: Software engineering topics I changed my mind on
#229>Java isn't that terrible of a language. That is going to evolve in the next six years to "languages don't usually matter much except in specific domains in a few cases"
I'm not sure about that. As an industry, we're just beginning to realize that object orientation is hurting far more than it's helping. As more people realize this, better tools and techniques will be devised to help developers think of their programs more like computers do: as data, and not as objects which only make sense to some humans. As such, PURE OOP languages like Java are going to start to fall out of favor…
Re: Software engineering topics I changed my mind on
#230True. It isn't a great language, but isn't terrible. What is terrible are the over-engineered, over-abstracted APIs that are relatively common in the Java ecosystem.