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

191–200 of 704 posts

Re: Software engineering topics I changed my mind on

#191

Post by busterarm »

pdimitar wrote: post #158
adamkl wrote: post #151

Earlier quoted context omitted.

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

Free Pascal.

That said, I'll use anything in my paid work if the project is interesting enough. Hence the three years I spent writing PHP.

Re: Software engineering topics I changed my mind on

#192

Post by conanbatt »

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 engineers that believe they would thrive without managers are likely the ones managers exist for.

It is simply absurd to believe that companies throw away billions down the tube for useless work.

Re: Software engineering topics I changed my mind on

#193

Post by Nycto »

potta_coffee wrote: post #185
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…

I don't understand splitting an API into a bunch of "microservices" for scaling purposes. If all of the services are engaged for every request, they're not really scaled independently. You're just geographically isolating your code. It's still tightly coupled but now it has to communicate over http. Applications designed this way are flaming piles of garbage.

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.

Re: Software engineering topics I changed my mind on

#194

Post by ithrow »

busterarm wrote: post #183
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…

> 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?

Re: Software engineering topics I changed my mind on

#195

Post by busterarm »

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 think this one is very much up to interpretation and will vary widely between people.

As for me, I spend way more time thinking and planning and picking apart ideas than I do writing code. Often this involves a pen and paper. Better abstractions come from planning rather than diving in and writing code.

Re: Software engineering topics I changed my mind on

#196

Post by tuke »

alain_gilbert wrote: post #27
dgs_sgd wrote: post #23

Earlier quoted context omitted.

Directly under "Things I've changed my mind on" the author writes "Things I now believe".

There is a new sentence in the "Things I've changed my mind on" section: > Things I now believe, which past me would've squabbled with: That phrase was not there originally when the article was posted.

Nice.

Re: Software engineering topics I changed my mind on

#197

Post by Clubber »

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.

For our team, we just do a weekly biz/dev meeting, then break into a pure dev meeting every Tuesday morning. The process takes about 30min - 60min a week and we can go into depth when needed. Plan the week and go do what we do. It works great for our small 5 man team.

Daily meetings seem excessive to me, even if they only last 5 minutes.

Re: Software engineering topics I changed my mind on

#198

Post by tikhonj »

closeparen wrote: post #175
crdrost wrote: post #137

Earlier quoted context omitted.

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…

It sounds like you and your team are working on the same artifact and that your tasks are interrelated. That’s kind of a special case. At any given time our 3 engineers have maintenance tasks in flight on 4 or 5 distinct products.

If people are working on completely unrelated things, what do you get from a stand-up other than a group status update?

Re: Software engineering topics I changed my mind on

#199

Post by busterarm »

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've hit on something there as well, but essentially it comes down to forced rewrites and flexibility. We tend to choose the more flexible systems to avoid forced upfront work when changes are needed even when it's the wrong choice for the project in the long run.

Re: Software engineering topics I changed my mind on

#200

Post by busterarm »

potta_coffee wrote: post #186
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…

I'm facing this issue now. App is supposed to deliver to clients after this sprint - and the data model still isn't locked down. After arguing through about 10 hours worth of meetings this week, I think I need a new job.

My condolences.
Post reply on HN