Live data from Hacker News

Software engineering topics I changed my mind on

chriskiehl.com

211–220 of 704 posts

Re: Software engineering topics I changed my mind on

#211
post #139

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…

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.

Agree about retrospectives. It's such a waste of time. Most of the time it's just there so that the scrum master can show off their new game and try to justify their usefulness.

Re: Software engineering topics I changed my mind on

#212

Earlier quoted context omitted.

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.

Most teams are silo'd like it or not. A backend guy or two, a frontend guy or two, layers of management, product, qa, ops people.

If I'm a backend person, I'll talk to the backend guy person if we messed up. If the frontend guys are lamenting among themselves, I find myself not really caring and time being wasted.

There's zero reason that teamwide changes can't be proposed for discussion via email or slack.

Re: Software engineering topics I changed my mind on

#213

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…

> Standups are useful for communication between a team in general, if kept brief.

Just once I'd like to work for a company that tries to stay in communication without so many explicit/manual/sync check-in gates.

* No stand-up, engineers required to write a 250-words or less blog post 2+ times a week.

* No announcing PRs, reviews &c to each other. Make watching the board a habit, one you "pull" rather than that is pushed to you. Or use a company provided chat-bot/tool to help surface changes as they happen, if you need that. The issue tracker should better dashboard whatever activity is happening, in general- indicate branch updates, pr changes, &c, clearly, across the board.

There's some value to using social processes to radiate all the changes happening, but I'd really like to see some camp out there that makes a go at mechanizing themselves. I think there are a lot of interesting possibilities, more enduring & valuable forms of communication that we have failed to even begin to explore.

Re: Software engineering topics I changed my mind on

#214

Earlier quoted context omitted.

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.

I'm curious. How did Free Pascal make you a better programmer?

Re: Software engineering topics I changed my mind on

#215

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?

Pen and paper are extremely useful for me, but I'm one of the only guys I know of that use pen and paper often.

Re: Software engineering topics I changed my mind on

#216

Earlier quoted context omitted.

Mine is that "this should never waste a user's time unless absolutely necessary." And it is absolutely shocking how many developers do not care if they make a user wait a minute for something that should take To me, it is a moral failing if my laziness costs user's time. Remember how many users you have and multiply delays by the number of users delayed by your code.

Yes but also don't overoptimize it's normally not worth it at all. The relevant decisions are often about the UI/UX design and flow as well as the architecture, but less about optimizing code sections here and there.

Yes, I failed to state that, as I felt it obvious, and you're right. Over-optimizing is just as bad as under-optimizing.

I will not spend 4 hours to save 5 users 5 minutes per year.

Re: Software engineering topics I changed my mind on

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

For me that's been Elixir. It's made me appreciate some of the more functional aspects in Python, like generators, map, filter and the functools library in general.

Re: Software engineering topics I changed my mind on

#219
Regarding testing, I've noticed that every time I've thought I've done enough manual testing (and I do a lot of that before I push to QA) and I can add the automated tests "later" due to time crunch or whatever, I've found issues when I got around to adding them. This experience has fundamentally changed how I view automated tests.
Post reply on HN