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

161–170 of 704 posts

Re: Software engineering topics I changed my mind on

#161

Post by [deleted] »

sanderjd wrote: post #77
woeirua wrote: post #62

The insane obsession with scaling is killing this industry. So much effort is being wasted trying to use NOSQL or K8s at companies that have DAU counts in the low hundreds. Absolutely asinine.

But is their business model targeting hundreds of DAUs, or is it targeting millions of DAUs? It doesn't make sense to architect for an amount of usage that is too small to sustain the business. If the business model requires millions of users to be successful, you should build for millions of users, even if you only have hundreds at the present moment.

[deleted]

Re: Software engineering topics I changed my mind on

#162

Post by dnautics »

brundolf wrote: post #157
dnautics wrote: post #115

Here's what i have to say about TDD (I do not practice TDD on a day-to-day basis). Even if you don't use it, you should know what it is. If you choose to use it religiously, that's probably a bad choice, but if you don't do it ever, you are missing out on a huge tool. In general, if I see an insurmountably complex challenge ahead of myself, sometimes TDD (especially detroit-style TDD) is a tool to refocus my attentio…

> how that break/fix loop can supercharge your productivity by giving you those dopamine rushes as a reward for your effort It's interesting to hear someone come out and say that there's a link between how "fun" a coding workflow is and how productive it is. I think most of us know it, but nobody ever talks about it. I wonder if it could be harnessed better.

It's kind of like a drug. I don't play any more video games - coding is my video game. I'm convinced that strategic use of those green dots is why I don't burn out much anymore, I just pushed through a month-ish emotional slog that in the past would have triggered full-on burnout but still wrote lots of code for work, my personal projects, and produced the deliverables for my job only a day-ish later than I said I would.

Re: Software engineering topics I changed my mind on

#163

Post by etxm »

> Pencil and paper are the best programming tools and vastly under used

I do most of my large work (not small features) on paper first in pseudo code and drawings.

It helps me think through a problem rather than code through a problem.

The TDD one seems directed at someone.

I was really anti-TDD until I lost a bet with a lead on my team about 15 years ago. I tried it for a few weeks and it really changed the way I develop - and I started delivering code faster (this was the bet).

Now-a-days, I don’t always write tests first. I definitely fool around or cowboy code sometimes especially when working with something new. Once I’ve figured out how to use the API, tool, or library; I delete my code and write tests to work through what my API will look like, then write my code.

Re: Software engineering topics I changed my mind on

#164

Post by Twisol »

arvinsim wrote: post #142
PragmaticPulp wrote: post #41

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…

> 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 microservices probably isn't justifiable.

(I, too, am in the position of pushing back against microservices for hotness' sake.)

Re: Software engineering topics I changed my mind on

#165

Post by etxm »

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…

I’ve always found DRY to only apply well to two things:

- business logic

- something that your extracting as a library

Re: Software engineering topics I changed my mind on

#166

Post by danfang »

roganartu wrote: post #145
danfang wrote: post #113

I agree with most of the points the author makes. > Pencil and paper are the best programming tools and vastly under used I'm not convinced of this one. I grew up with digital tools only. Can someone give me examples where this assertion is true?

> I grew up with digital tools only. This implies that you exclusively use digital tools, so my first question would be: have you tried using pen and paper for things? It's really hard to give compelling examples of where pencil/pen and paper are going to be better than digital tools because everyone is different. If you want to try it out, I recommend simply keeping a pad and a pen at your desk and when you're stuck…

> have you tried using pen and paper for things?

Yes.

If I can express something through writing (as with the cases you mention), there is no faster, more convenient tool than a note taking app + keyboard. It's instant, archived, editable, and globally available (where there's internet of course).

If it's an idea that needs to be visually designed (shapes, graphs, space), I find that I can mostly do this by redefining the problem in a way that can be written down.

There's a small percentage of time where having a diagram is truly essential to my workflow. I'm not opposed to whiteboarding in these cases, but it's not as vital to my process as the author implies it is for them.

> indescribably helpful

I tend not to be convinced by things that are indescribable. What I'm understanding is that it's a tool that makes you happy. That's sometimes a valid enough reason to do something.

Re: Software engineering topics I changed my mind on

#167

Post by joseph_grobbles »

silentsea90 wrote: post #147
joseph_grobbles wrote: post #94

Earlier quoted context omitted.

"10 minutes" Are you the only one attending or something? Standups are initially scheduled for the start of the development day. But then people come in a little late, get that first minute call, have to attend to something that hiccupped, so soon enough the standup happens 30 minutes into the day, eventually an hour into the day. So if you did get there on time, now you just spin your wheel waiting, because first yo…

I am not sure where you work, but I am surprised that with such a lackadaisical attitude towards attending a meeting, any work gets done at all. If you have a meeting at 11 AM in the morning, people are supposed to show up on time. Do all your meetings run late? Or does only the standup get this treatment? Sidenote: if somebody's late > 2 mins, they can join midway or miss the standup altogether, just as is the case…

I've worked in three fortune 500 companies (banking and finance). Several SV tech companies (in satellite offices - not in SV). Two pure startups. An engineering firm. I have never seen it be anything but a waste of time. And it always consumes significantly more time than the boosters claim it does.

And we can look at each other's anecdotes with suspicion. But there's a paradox that when someone says "Oh it's only 1 minute per person" then my natural response is "why isn't that a status line they set in IM or something?" at whatever asynchronous time it suits them best in their workday. How could it possibly be the best way to communicate 60 seconds of information by making everyone break their flow and gather together. And if it's more than 1 minute, and you're getting into actual meat, well then there are even bigger issues afoot like an inappropriately large and inefficient audience.

If you're just stating exactly what everyone can see in JIRA or whatever product you use, then it's a waste of time.

Aside: In probably half those teams there were remote developers who'd have to call in. Boy, that added a whole new fun level where everyone does nothing while technical issues are sorted.

EDIT: After the flurry of downvotes by these scrum disciples, I can't even reply to the disingenuous reply to this that makes some astonishing projections, and again tries to moral high ground.

If you are on a team that derives value from scrums, you are probably on a shitty team.

Debating with the zealots of scrum land (who, like the guy below, will repeatedly tell you -- in between their evangelizing -- that they're not really zealots) is a Schrödinger's Cat of productivity, where not only does it take no time and impose no flow penalty, completely and fully detached with every inkling of software development knowledge industrywide, it also conveys everything to everyone and is all powerful.

Re: Software engineering topics I changed my mind on

#168

Post by pseudalopex »

sanderjd wrote: post #77
woeirua wrote: post #62

The insane obsession with scaling is killing this industry. So much effort is being wasted trying to use NOSQL or K8s at companies that have DAU counts in the low hundreds. Absolutely asinine.

But is their business model targeting hundreds of DAUs, or is it targeting millions of DAUs? It doesn't make sense to architect for an amount of usage that is too small to sustain the business. If the business model requires millions of users to be successful, you should build for millions of users, even if you only have hundreds at the present moment.

Someone told me once it's more important to design things to scale 1 or 2 orders of magnitude and be easily replaced. What you think you'll need 2 or 3 orders of magnitude from now is rarely what you need when you get there.

Re: Software engineering topics I changed my mind on

#169

Post by Jcampuzano2 »

arvinsim wrote: post #142
PragmaticPulp wrote: post #41

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…

> 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 to basically infinity.

Re: Software engineering topics I changed my mind on

#170

Post by john-shaffer »

dnautics wrote: post #162
brundolf wrote: post #157

Earlier quoted context omitted.

> how that break/fix loop can supercharge your productivity by giving you those dopamine rushes as a reward for your effort It's interesting to hear someone come out and say that there's a link between how "fun" a coding workflow is and how productive it is. I think most of us know it, but nobody ever talks about it. I wonder if it could be harnessed better.

It's kind of like a drug. I don't play any more video games - coding is my video game. I'm convinced that strategic use of those green dots is why I don't burn out much anymore, I just pushed through a month-ish emotional slog that in the past would have triggered full-on burnout but still wrote lots of code for work, my personal projects, and produced the deliverables for my job only a day-ish later than I said I wo…

> It's kind of like a drug. I don't play any more video games - coding is my video game.

I feel the same way. I just make sure I take one full day off a week and play games or read. I can still get burned out, but it's generally short-lived.

Post reply on HN