Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

651–660 of 704 posts

Re: Software engineering topics I changed my mind on

#651

Post by mint2 »

bena wrote: post #642
mint2 wrote: post #636

Earlier quoted context omitted.

1. “I am a veterinarian and recruiting is way more straightforward” 2. “Also I just changed jobs and was able to write code quickly because they were recruiting with tasks in mind for me.” Is no one else confused by this? How common is a coding veterinarian and why do veterinarians write code?

I just took it to mean they were a veterinarian and now they work as a programmer.

But the first is in present tense, and the second says jobs not fields. It’s enough to be very unclear.

Re: Software engineering topics I changed my mind on

#652

Post by AnimalMuppet »

skohan wrote: post #423

Very good list in general, but I would disagree with one point: > Software architecture probably matters more than anything else The devil is in the details here, but the more I program, the less I feel that "software architecture", at least as it is often discussed, is actually not important and often actively harmful. The architecture driven approach takes the assumption that the "correct" shape of a program should…

So you don't think architecture matters that much, but you've felt the pain of having one that doesn't fit forced on you? That seems... kind of unaware of you.

Just-in-time architecture is a perfectly valid approach to developing an architecture. The point is to develop one that is a good match to the problem. If you don't have that, you suffer - and that's the point of what you quoted.

Re: Software engineering topics I changed my mind on

#653

Post by jackfoxy »

mint2 wrote: post #647
jackfoxy wrote: post #253

Stick with languages, tools, and techniques that respect the math theory. Category theory, type theory, set theory, relational algebra, 1st order predicate calculus, 2nd order predicate calculus. The OP has intuitively gravitated to this side. Theory isn't going to have an answer to every question, just don't willfully oppose it. Everything else (best practices, fads, etc.) is a convention at best, sometimes useful,…

Not having a formal cs background, the comments on HN that wax about predicate calculus and algebras always raise questions for me. Is it a higher plane of programmer thinking or just abstract technical jargon and ideas that are suited for hard core technical cs research but bear little value in practical programming tasks? Like knowing the Latin names and full phylogenic tree and exact relation of humans to the anim…

It kind of boils down (for me) to choosing a strongly typed functional language and relational database by default, justified by the theory behind those.

I can be convinced, by myself or others, that a particular project calls for something else.

Because I'm familiar with them and satisfied with the tools my defaults are F# and SQL Server.

Re: Software engineering topics I changed my mind on

#654

Post by AnimalMuppet »

datascience91 wrote: post #160
mixedCase wrote: post #110

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?

You sound either like English isn't your first language, or like you're taking words far too literally.

In the sense we're using, a tool is anything we use to do what we're trying to do. A physical tool is a tool. A software tool is a tool. But if I'm trying to ship something, FedEx and UPS are tools (in this larger sense).

So an abstraction, a way of thinking, a way of writing code, is also a tool. I can use FP for the problems that it fits well, and use other ways of programming on other problems. "It's just a tool" means "it's not The One Right Way". Use it when it fits. Don't use it when it doesn't.

Re: Software engineering topics I changed my mind on

#655

Post by skohan »

AnimalMuppet wrote: post #652
skohan wrote: post #423

Very good list in general, but I would disagree with one point: > Software architecture probably matters more than anything else The devil is in the details here, but the more I program, the less I feel that "software architecture", at least as it is often discussed, is actually not important and often actively harmful. The architecture driven approach takes the assumption that the "correct" shape of a program should…

So you don't think architecture matters that much, but you've felt the pain of having one that doesn't fit forced on you? That seems... kind of unaware of you. Just-in-time architecture is a perfectly valid approach to developing an architecture. The point is to develop one that is a good match to the problem. If you don't have that, you suffer - and that's the point of what you quoted.

I think this is a bit of a stretch. The assertion I took issue with is that "Software architecture probably matters more than anything else".

Yes if you want to deconstruct the term to the point of absurdity, and say that whatever shape your program ends up in implies some "software architecture" then you can say architecture is always relevant, but I would consider it a stretch to say this means it's also the number-1 priority in software development.

If you read my comment, you would see that I'm arguing that software results, and software development as a process matter much more than thinking about architecture. I would also argue that every time the term "architecture" came up in a professional discussion over the past several years, this was a sign we were going down the wrong path.

Re: Software engineering topics I changed my mind on

#656

Post by lytefm »

deanCommie wrote: post #626
koonsolo wrote: post #389

Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity trumps all other concerns. My measurement is "simple and clean" code. Is it simple and clean? No? make it so! > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. If a good developer you…

Another 20 year veteran here. (though don't picture a greybeard, I started professionally at 15) The big lesson for me over the last 5 years now that I also operate my code is design patterns. I think most Software people start with hating design patterns, then some fall in love with them, then eventually some of us fall out of love again. The advice would be: "Optimize code cleanliness and readability for reading at…

> I went from thinking "Comments are great!" to "Comments are terrible, and are liars, write self-documenting code" to "Comments are literally an opportunity for you to speak directly to the person coming after you, and explain in clear plain english WHY you made the choices you did, what tradeoffs you considered and dismissed, what compromises you made, and what external factors led to those decisions."

Wholeheartedly agree. Also, debugging logs for that same purpose can be great.

> Speak directly to your audience of future more junior engineers.

Often enough, that person might be yourself. I've been very grateful about my own comments in code areas that handled some obscure edge cases.

> That means every jump to another class and every jump to an interface with multiple implementations is a distraction.

Not to mention multiple layers of abstract base classes. I'd say „write your code such that you'll only ever need one IDE jump out of the current scope (and back in) to figure out what's going on“

Re: Software engineering topics I changed my mind on

#657

Post by alexb7c4 »

Jcampuzano2 wrote: post #169
arvinsim wrote: post #142

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?” Funny you mentioned this. I have the exact opposite problem. That is, I am an engineer trying to push back against management mandating the use of microservices and microfrontends because they are th…

This. I'm a consultant and 90% of the time the technology has already been decided by our fancy management team who haven't written code in 10+ years before a line of code has been written. But they know the buzzwords like the rest of us and know they sell. Problem is they no longer have to implement, so they are even more inclined to sell the most complicated tech stack that have marketing pages claiming they scale…

In my company we store financial data for hundreds of thousands of clients in sql db. It's decade okd system and we have hundreds of tables, stored procedures (some touching dozen+ tables) and rely on transactions.

It took me weeks to convince my managers not to migrate to new hot nosql solution because "it's in cloud, it's scalable and it also supports sql queries".

Re: Software engineering topics I changed my mind on

#658

Post by lytefm »

rmk wrote: post #290
bawolff wrote: 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,…

People with less experience consistently undervalue linting and code formatting and style. Code linting forces one to deal with code smells and innocuous errors that can cost a lot to fix once they escape into the field. Consistent code formatting and style are invaluable in (a) reducing cognitive load in picking names, which is a hard problem in computer science, (b) clarifying the structure of the code (you begin t…

> (c) onboarding or familiarising with new codebases, including new areas of large codebases.

It is extremely useful to lower the cognitive overhead when looking into different areas of the codebase. Inconsistent naming patterns, „magic” strings instead of enums, preferences about array iterations, using deprecated features etc shouldn't need to part of a code review if they can be detected automatically instead. This is especially useful for junior devs.

Re: Software engineering topics I changed my mind on

#659

Post by lillecarl »

anthuswilliams wrote: post #644
lillecarl wrote: post #465

Earlier quoted context omitted.

What is the upside of a higly diversified worksforce? Where I work we're all white males age 20-60 except accounting, they're white females around age 30. What's bad about this? What value does it bring to diversify, what should we look for and why is it important? Or are we too small to need diversifying yet with only about 30 employees?

This is a question I wrestled a lot with. Growing up, diversity was not something I thought a lot about, and in any case I have always considered myself a hard-nosed type of thinker, for whom concerns about quality and the bottom line should _always_ outweigh the messy questions of identity politics. But these days I work at a much more diverse organization than the one in which I started my career and what I have re…

I actually see the cargo-cult tendencies quite a bit, I'm working as hard as i can to question everything we're doing and how we're doing it. Not a very rewarding task, but if you don't you're obsoleted by others.

Re: Software engineering topics I changed my mind on

#660

Post by Nycto »

potta_coffee wrote: post #235
Nycto wrote: post #193

Earlier quoted context omitted.

The first thing that comes to my mind is that there are different axes that you may need to scale against. Microservices are a common way to scale when you’re trying to increase the number of teams working on a project. Dividing across a service api allows different teams to use different technology and with different release schedules.

I don't necessarily disagree, but I believe that you have to be very careful about the boundaries between your services. In my experience, it's pretty difficult to separate an API into services arbitrarily before you've built a working system - at least for anything that has more than a trivial amount of complexity. If there's a good formula or rule of thumb for this problem, I'd like to know what it is.

I agree. From my perspective, microservices shouldn’t be a starting point. They should be something you carve out of a larger application as the need arises.
Post reply on HN