Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

221–230 of 704 posts

Re: Software engineering topics I changed my mind on

#221

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…

Yeah, god helps if a higher up is a zealot about a technology. They will try to suggest that at every opportunity and arguing against it makes you stand out like a sore thumb that after a while you wonder why you even bother.

Re: Software engineering topics I changed my mind on

#222
post #66

11 years in and my one critique is: >Designing scalable systems when you don't need to makes you a bad engineer. You have to have a very good understanding of the 'need' ahead of time or you're effectively just playing a kind of lotto. Do the bare minimum and it meets the need, you win. Do the bare minimum and it doesn't, get ready to start over, you lose.

I disagree. Well designed systems can normally be scaled, the scaling problems are generally well understood. Scaling prematurely is silly and costs a lot of time and effort to support customers that don't exist.

Re: Software engineering topics I changed my mind on

#223

Earlier 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.

Ironically Elixir has become a personal favourite and I find it amazing for backend web work, especially API gateways -- although it does very well with server-side rendering web projects as well. It's my main work tool (very close second is Rust).

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
> Designing scalable systems when you don't need to makes you a bad engineer.

> In general, RDBMS > NoSql

I use NoSql because RDBMS is a premature optimization for me

My experience with ORMs especially ORMs I didnt chose is that they are frail, assume too much and I often end up writing my own plain text queries anyway, all so that I can get a result from the database in object form, but without bogging down the database with inefficient queries

NoSql is object and collection based by default, and any Orm-like necessity is standardized with that database, instead of with a third party under-maintained library

My projects dont need to brag in an engineering blog about scalable performance, and the memcache solves all bottlenecks I’ve ever encountered

Re: Software engineering topics I changed my mind on

#225

According to the author, FP is another tool. No, Functional Programming is NOT a tool but a paradigm which is a formal system of computation based only on function called lambda calculus.

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".

[deleted]

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 this were true, it would make no difference if one uses assembly or Java or use a magnetic needle to swap bits. But it's clear to everyone that it makes a big difference.

If someone says "language doesn't matter" it usually means they suffer from the blub paradoxon.

Re: Software engineering topics I changed my mind on

#227

Earlier 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?

People regularly say "the right tool for the job". When it comes to software that can mean any decision you make on what to use for solving your problem: language, OS, IDE, editor, architecture, low or high level design, etc.

Re: Software engineering topics I changed my mind on

#228
post #21

Usually i disagree with these types of lists, but this one seems pretty spot on. My only quible would be that only code quality static analysis is useful. Security static analysis on the other hand (e.g. taint analysis to find security bugs like XSS) is pretty overrated most of the time unless you work really hard to make it fit in your context. I also think linting rules are important, not for what they actually do,…

> 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…

Reminds me of this:

"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…

I hope Java and .NET fall into disuse, I've never enjoyed programming less. I'm not a fool, I recognize that some great software can be created with those tools, but it just feels so much more painful to work with. It must be my taste.
Post reply on HN