Software engineering topics I changed my mind on • Hacker News Board

Re: Software engineering topics I changed my mind on

#201

Post by ncann » Sun, Jan 24, 2021, 4:09 AM UTC

tikhonj wrote: post #189

windowshopping wrote: post #82

Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently lo…

A bit of a controversial take: if you need standups for this sort of communication, your work and work culture are way too siloed. With a flexible and collaborative culture, people will communicate these things naturally as part of doing their work. Issues that come up will get addressed as needed when they come up . If something is important, why would you wait for tomorrow's standup? If something isn't important, w…

While you have a point, it's not that rare for someone to be blocked on a hard issue for a day or two, even having talked to someone, then bring that up at the stand-up. The one you talk to may not always have the solution, and it may be someone else in the team at large.

Re: Software engineering topics I changed my mind on

#202

Post by pseudalopex » Sun, Jan 24, 2021, 4:09 AM UTC

eyelidlessness wrote: post #187

axaxs wrote: post #139

Earlier quoted context omitted.

Same here. Well everything except retrospectives, which I think are generally wasteful or better done in small pieces. Was afraid I wouldn't see something about overdoing microservices, but I think the monolith line covers it enough.

Retros should be like recall elections: always available, never scheduled, with a high but achievable barrier to entry and specific veto principles both ways. The point of a retrospective is "something big happened and we should learn and adapt". They shouldn't be routine, because most weeks/sprints, nothing that big happened (or something that big happened too frequently/urgently to wait for a calendar). They should…

It shouldn't take something big to reflect on what went well and what didn't. Or suggest a change.

Re: Software engineering topics I changed my mind on

#203

Post by quelltext » Sun, Jan 24, 2021, 4:10 AM UTC

free_rms wrote: post #125

ng12 wrote: post #61

> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency. I was just thinking about this. Most PMs remind me of that scene from Office Space: "Engineers are not good at dealing with customers. I have people skills!". There's no need to insulate engineers from the products they work on and the customers they work for. Good engineers want ownership, let…

The linked post said project manager. Good PRODUCT managers, in small numbers, are worth their weight in gold IMO. Researching/talking to users takes time, making decks takes time, stepping back and surveying the landscape takes time. It's worth having someone doing that.

Oh god, I hate the PM abbreviation. Product managers and project managers have a bit of overlap (as the former also do project management to an extent, just like engineers), but they are different and having them provides different benefits. Why do we abbreviate both with PM? I never quite know which is referred to.

Re: Software engineering topics I changed my mind on

#204

Post by Shorel » Sun, Jan 24, 2021, 4:10 AM UTC

windowshopping wrote: post #82

Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently lo…

Every time I mention the goodness of pencil and paper I get downvoted by so many youngsters.

Some people will always disagree about some points. It's in their nature.

Re: Software engineering topics I changed my mind on

#205

Post by potta_coffee » Sun, Jan 24, 2021, 4:11 AM UTC

DDSDev wrote: post #6

> DRY is about avoiding a specific problem, not an end goal unto itself. To add on to that, I think the key behind DRY is to not repeat a concept within your codebase, and not failing into the trap of avoiding similar but slightly different code blocks that aren't exactly logically equivalent by carving up your code into nonsense. The former leads to elegant abstraction, while the latter just leads to functions with…

It requires subtle thinking. Instead what I see a lot of the time is the "rule" of DRY applied with religious fervor, and it produces the kind of code I enjoy working with the least.

Re: Software engineering topics I changed my mind on

#206

Post by tikhonj » Sun, Jan 24, 2021, 4:11 AM UTC

ithrow wrote: post #194

busterarm wrote: post #183

Earlier quoted context omitted.

> Frankly, many engineers want to use the latest trends like microservices or NoSQL because they believe that’s what’s best for their resume, even if it’s not necessarily best for the company. Probably nobody is using NoSQL for their resume. It's because picking a relational database, while usually the correct choice, is HARD when you're operating in an environment that changes quickly and has poorly defined specific…

It's because picking a relational database, while usually the correct choice, is HARD when you're operating in an environment that changes quickly and has poorly defined specifications. Wouldn't this apply if you are using a static typed language too? what's harder about changing the schema in the DB?

You (mostly) don't have to deal with data migrations with statically typed languages. Releasing a new version of some code is usually easier than making structural changes to a database that's in active use.

Re: Software engineering topics I changed my mind on

#207

Post by zbobet2012 » Sun, Jan 24, 2021, 4:12 AM UTC

Shorel wrote: post #204

windowshopping wrote: post #82

Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently lo…

Every time I mention the goodness of pencil and paper I get downvoted by so many youngsters. Some people will always disagree about some points. It's in their nature.

I disagree. The best medium is a whiteboard or a blackboard :p.

(Really though, something about paper makes me afraid to "commit" things which make the pieces of paper no longer usable. Something made to be erased seems to be the trick for me).

Re: Software engineering topics I changed my mind on

#208

Post by GIFtheory » Sun, Jan 24, 2021, 4:12 AM UTC

mixedCase wrote: post #108

wegs wrote: post #19

I predict the following changes: 1) Typed languages are worse, and you want people with high levels of competence. 2) Java actually IS terrible. You win very little by designing for incompetent coworkers. Plan for competence, and hire appropriately. Small elite teams beat large incompetent teams every time. See #1. 3) Thinking through scalability upfront matters in many systems. Not all systems. Many systems. 4) SOLI…

Hard agree with 4 and 5. Soft agree with 6, I think there's nothing's wrong with sharing specially since many of the important teachings are incompatible with the kind of people for whom these lessons are not obvious after a couple of years of experience. But points 1 to 3 give me a visceral negative reaction. I'll go into detail: 1) If you're writing anything that's not a script with a few lines, and you care about…

> 1) If you're writing anything that's not a script with a few lines, and you care about your software not being terrible to maintain and change for other people in real production settings, typed languages wipe the floor with dynamic languages (excluding ecosystem moats, just judging the languages).

I really hope the typed-vs-not-typed debate is over... types > no types. However... I used to believe that types were essential. I now believe that they are more like a luxury. Good tools are a luxury, not fundamental—it’s way more important to have good software design, and the core of good software design is really tool-independent. It requires deep understanding of whatever problem you’re trying to solve, not a deep understanding of software tools—-unless you’re unlucky enough to be building some horrible middleware.

I also like to dabble in photography, where you see a similar phenomenon. When I take a really great photo, people sometimes remark, “wow, you must have a really great camera!” No, actually, that’s the least important part of the equation. There’s a reason why Canon’s top-of-the line lenses are the “L” series—the L is for luxury. They make the job a little easier, but they’re not really essential.

Re: Software engineering topics I changed my mind on

#209

Post by pseudalopex » Sun, Jan 24, 2021, 4:12 AM UTC

Twisol wrote: post #164

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…

On my reading, this is the exact same problem, not the exact opposite problem. The break-even bar for a reasonable monolith is a lot lower than for microservices, so the GP's question is specifically asking, under a hypothetical where the team simply uses a monolith, what benefits the team would miss out on relative to microservices. If there are none, or they aren't relevant to the project scenario, then microservic…

The point is it can be engineers pushing back against managers. Not just managers pushing back against engineers.

Re: Software engineering topics I changed my mind on

#210

Post by ffhhj » Sun, Jan 24, 2021, 4:13 AM UTC

systemvoltage wrote: post #180

windowshopping wrote: post #82

Have never agreed with a blog post more. Every single bullet point, 10/10. Okay, okay, actually I have one qualm~ > Standups are actually useful for keeping an eye on the newbies. Unfair. Standups are useful for communication between a team in general, if kept brief. If senior engineer X is working on Y and other engineer M has already dealt with Y (unbeknowst to X), it's a great chance for X to say "I'm currently lo…

Let’s be honest, stand ups are there so we can get together as a team. Otherwise, engineers would be heads down working on their own things. Benefits of “Oh I yea I’ve worked on the same thing before” are usually realized outside of stand ups in over the shoulder chats or slack. Stands ups are a waste of time. There, I said it. But, I like them, especially if you have a fun team.

Agreed!

Stand ups are a teather play to make the client believe a project is moving forward, while team members use their own private channels to talk about the real work.