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

151–160 of 704 posts

Re: Software engineering topics I changed my mind on

#151

Post by adamkl »

pdimitar wrote: post #64

> Functional programming is another tool, not a panacea. That's extremely true and I am not denying it. I'd like to add the nuance that us the Homo Sapiens seem to operate better when we are pushed into the right direction. Giving us too much choice -- like global mutability and OOP in general -- can cause analysis paralysis and make people do all sorts of panicked dumb choices in their software projects. As a guy wi…

> So while FP is just another tool, it's also a framework for thinking that helps people make better choices

I’ve been getting more into functional programming this past year (via Clojure, though my day-job is mostly JavaScript/TypeScript) and this is the big takeaway for me.

Type theory and monads may have their place, but thinking about separating logic from side-effects is, I think, the most valuable aspect of functional programming.

That is a thought process that you can apply in pretty much any language that will give you the biggest bang for your buck.

Edit: Here’s some great examples of the benefits of functional thinking without going off the deep end.

1. Boundaries by Gary Bernhardt - https://www.destroyallsoftware.com/talks/boundaries

2. Pits of Success by Mark Seemann - https://youtu.be/US8QG9I1XW0

3. Grokking Simplicity by Eric Normand - https://grokkingsimplicity.com/

Re: Software engineering topics I changed my mind on

#152

Post by Aeolun »

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…

I think the best part of doing test driven development (or similar) is that making your code easily testable generally also makes it architecturally sound.

Re: Software engineering topics I changed my mind on

#153

Post by dnautics »

Aeolun wrote: post #152
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…

I think the best part of doing test driven development (or similar) is that making your code easily testable generally also makes it architecturally sound.

Refactoring is quadratically more difficult if you don't have tests.

Re: Software engineering topics I changed my mind on

#154

Post by Gibbon1 »

blabitty wrote: post #51
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…

I like to half jokingly assert that microservices are a pysop to sell cloud hosting

I've long thought that Java write once, run anywhere, really was a desperate attempt to save Sun's legacy server market from doom.

Re: Software engineering topics I changed my mind on

#155

Post by reader_mode »

PragmaticPulp wrote: post #41
cbdumas wrote: post #13

> Designing scalable systems when you don't need to makes you a bad engineer. > In general, RDBMS > NoSql These two bullet points resonate with me so much right now. I'm a consultant and a lot of my client absolutely insist on using DynamoDB for everything . I'm building an internal facing app that will have users numbering in the hundreds, maybe. The hoops we are jumping through to break this app up into "microservi…

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 apply. To do this you usually rely on experience so you need to expand even further.

And the other side is usually attached to their proposal and starts pushing back and because you're the guy arguing against something and need a deep discussion to prove your point chances are people give up and you end up looking hostile. Even if you win you don't really look good - you just shut someone down and spent a lot of time arguing, unless the rest of the team was already against the idea you'll just look bad.

I just don't bother - if I'm in a situation where someone gives these kind of people decision power they deserve what they get - I get paid either way. And if I have the decision making power I just shut it down without much discussion - I just invoke some version of 'I know this approach works and that's good enough for me'.

Re: Software engineering topics I changed my mind on

#156

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

#157

Post by brundolf »

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.

Re: Software engineering topics I changed my mind on

#158

Post by pdimitar »

adamkl wrote: post #151
pdimitar wrote: post #64

> Functional programming is another tool, not a panacea. That's extremely true and I am not denying it. I'd like to add the nuance that us the Homo Sapiens seem to operate better when we are pushed into the right direction. Giving us too much choice -- like global mutability and OOP in general -- can cause analysis paralysis and make people do all sorts of panicked dumb choices in their software projects. As a guy wi…

> So while FP is just another tool, it's also a framework for thinking that helps people make better choices I’ve been getting more into functional programming this past year (via Clojure, though my day-job is mostly JavaScript/TypeScript) and this is the big takeaway for me. Type theory and monads may have their place, but thinking about separating logic from side-effects is, I think, the most valuable aspect of fun…

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.

Re: Software engineering topics I changed my mind on

#159

Post by 01100011 »

marcinzm wrote: post #128
01100011 wrote: post #81

Earlier quoted context omitted.

In my experience, a PM handles a lot of the crap work that engineers shouldn't be working on. A PM keeps management apprised of progress. A PM handles the work involved in keeping Gantt charts up to date. A PM coordinates with dependents and dependencies to make sure resources and components are available when needed. If you don't appreciate the value of that, you maybe have worked on smaller projects or not been in…

>A PM keeps management apprised of progress. In most places, project managers save managers time by not requiring managers to spend their time figuring out the progress of things. However because PMs have more bandwidth they take up even more engineer time than managers would.

IME a PM takes time at the beginning of the project to define tasks, dependencies, and time estimates. After that, you meet with them formally once every 1-4 weeks as a team to update the schedule, along with an informal, individual chat as needed for critical tasks and late dependencies. It took a lot less time than the useless daily standup meetings I now attend.

Most of my experience with PMs was at smaller orgs with smaller teams. Now that I work at a large valley company with layers of antagonistic management, I appreciate my former PMs more than ever.

It's important to hire good PMs without huge egos or career aspirations. Being a PM is kind of a shit job and it's not about wielding power or authority over people. You also need PMs who understand the uncertainty baked into software estimates, and can cope with unforeseen problems requiring schedule juggling.

Re: Software engineering topics I changed my mind on

#160

Post by datascience91 »

mixedCase wrote: post #110
datascience91 wrote: post #40

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

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?
Post reply on HN