Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

511–520 of 704 posts

Re: Software engineering topics I changed my mind on

#511

Earlier quoted context omitted.

Agreed. It’s a deliberate inefficiency to make sure you at least have a chance to communicate with your team on a regular basis. Otherwise you might go days or weeks without the chance to have a critical two minute conversation.

That sounds suspiciously like your team is not communicating enough in the first place though. I mean, I guess the profession does get its fair share of introverts, but I would have expected enough teamwork that everyone knows what everyone else is doing, at least roughly. At my last gig I remember we had three backenders and four frontenders on a game we were building and the stand-ups seemed superfluous, Ryan on th…

> That sounds suspiciously like your team is not communicating enough in the first place though.

That's probably true. There definitely exist teams that communicate well enough that the benefit of a standup is nearly nonexistent. But many teams aren't like that and have a handful of people who need a structured process for communication or they will struggle. Standups aren't the best solution, but they are an easily implemented way of getting a team part way there.

Re: Software engineering topics I changed my mind on

#512
post #52

Earlier quoted context omitted.

There are specific cases where a non SQL database is better. Chances are if you haven't hit problems you can't solve with an SQL database you should be using an SQL database. Postgres is amazing and free why would you use anything else.

People keep saying there are specific cases where NoSQL is better, but never what any of those cases are.

Here you go, this is from a system I helped building 10 years ago that is an eternity in tech - https://qconlondon.com/london-2010/qconlondon.com/dl/qcon-lo...

Re: Software engineering topics I changed my mind on

#513
post #480

Earlier quoted context omitted.

If you don't see the value in having a diverse workforce and company at any scale, I doubt anything I can say will convince you. There's enough research out there showing the benefits, if you're willing to take just a few minutes to go look for it. Your competitors will read that research. edit: carlhjerpe is right- this is super condescending. Downvote me.

That's very condescending. I'm asking because I don't see why my colleagues would be any better than they are if they were black, brown, jewish, muslim, female in various combinations, maybe I hold my colleaguestoo high?

> That's very condescending

You're right. I apologize. Often times in tech, the people asking questions like that are uninterested in the answers.

My own view is that I have been blind to the advantages that my background (white, male, straight, upper-middle-class) has given me for my entire life over other friends and colleagues. And I'm trying to learn more, read more, and pay more attention to these things.

Ijeoma Oluo, who I mentioned above, comes from tech. She saw a lot of things that you and I wouldn't notice. Things that matter, and we don't even see it. So she writes, she talks, and she makes a lot of great points. And it's really hard to read and listen to her sometimes because she makes points that part of me does not want to hear.

So that's the ethical reason why it matters.

As to the original question: Diversity of backgrounds can lead to diversity of ideas. Not on every problem. Not every day. But often enough that it can matter. And it can happen in many cases that you and I would not expect or predict. More diversity of ideas leads to better solutions being found. That's the premise- you don't have to believe it and many don't.

In the 1980s, Frito-Lay's CEO, who had never imagined the Latino market, put out a call for ideas. A Latino janitor answered the call with his idea- Flamin' Hot Cheetos. It was a huge hit. Imagine how many markets they (and others) were missing because of a lack of diversity of ideas.

Re: Software engineering topics I changed my mind on

#515

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…

To me this is a little bit weird, because while OP is totally correct in that monoliths are totally fine too when it's the best tool for the job, the default should still be microservices. It's not really harder to use once you have the practice in place and advantages will usually be quite visible in time. But of course there are times when there are great monoliths you can just use and you should use them.

There are challenges with microservices that hints me to build monoliths by default unless not viable.

Things that are trivial in monoliths are hard in microservices like error propagation, profilling, line by line debbugging, log aggregation, orquestration, load balancing, health checking and ACID transactions.

It can be done but requires more complex machinery and larger teams.

Re: Software engineering topics I changed my mind on

#516
post #456

Earlier quoted context omitted.

> If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough. A talk I watched recently by Ijeoma Oluo made a point I had never considered before: statistically, most people refer friends, and most friends are of a similar background, race, culture, gender, etc. It's not intentional- people aren't going out of their way to only refer p…

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?

Several benefits.

1. People with different backgrounds and experiences may notice important product features that you missed. The person who uses a screen reader is probably going to notice accessibility problems faster than the rest of the team.

2. There exist a lot of qualified people who aren't white. If your hiring process is failing to hire these qualified people due to internal biases then you are hiring suboptimally.

3. Social injustice is heritable and building a diverse workforce helps the world (in a small way) shift towards being more equitable.

Re: Software engineering topics I changed my mind on

#517

>>> Typed languages are better when you're working on a team of people with various experience levels I picked up the opposite qualm after working in a multi million line codebase in python, that goes back almost 2 decades in a large bank. Dynamically typed languages actually work, at all scale. Statically typed languages are good for simple types (int/string) but they're catastrophic for complex types (dict, map, da…

The big benefits are types-as-documentation and automated tooling.

Re: Software engineering topics I changed my mind on

#518

Earlier quoted context omitted.

> not helpful is when standups are treated like status reports > simply state what you’re doing Honest question, what's the difference.

I would suggest the difference is if you feel pressure about your response. Is it ok to pass, or say something like "still working on same issue I discussed a couple of days ago"? If not, it's less like a casual conversation, and more like justifying your time.

I would say that's perfectly okay, but not for the reason you think. If your status is "still working on the same issue", your team should respond with "how can we help?". If your status doesn't change, that's a sign that something's wrong at some level, whether it's because you're stalled or because the issue was poorly scoped or poorly defined.

Re: Software engineering topics I changed my mind on

#519

Earlier quoted context omitted.

I'm glad I've reinvented the wheel that many time as a junior, it let me learn why some framework and some solutions are the way they are, and made it extremely easy to pick up third party solutions later on

We'll never know the counterfactual, but in my opinion: You could have learned the same thing more efficiently, with more support for why you didn't need to reinvent the wheel.

I've been a professional software developer for ten years, and I'm on a hiatus right now. One thing I've been doing with my time is reinvent a bunch of wheels, implementing broken clones of this library or that algorithm, and I've gained a tremendous amount of understanding of what's going on behind the scenes of tools I'd been using for years. So yeah, it's a valuable learning tool to build with your own hands.

Also, a valuable guide when deciding whether to write code yourself or introduce yet another library to your dependencies.

Re: Software engineering topics I changed my mind on

#520

Is it just me or do those things seem very... obvious? I mean - almost every single one of them makes me question how can you even have a differing opinion that wouldn't immediately make you seem like you're mindlessly repeating hype phrases.

Common sense isn’t common, and sometimes it helps to write down the obvious.

Obviously planes should only land with the gear down, yet not all planes have. Hence the use of checklists stating the obvious: lower the gear.

Post reply on HN