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.
Software engineering topics I changed my mind on
211–220 of 704 posts
Re: Software engineering topics I changed my mind on
#212Earlier 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.
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
#213Have 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…
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
#214Earlier 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.
Re: Software engineering topics I changed my mind on
#215I 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?
Re: Software engineering topics I changed my mind on
#216Earlier 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.
I will not spend 4 hours to save 5 users 5 minutes per year.
Re: Software engineering topics I changed my mind on
#217Earlier 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.
Re: Software engineering topics I changed my mind on
#218TDD can be reframed as codified specifications with test verifications. Then, the TDD purists do have a point.
Re: Software engineering topics I changed my mind on
#219Re: Software engineering topics I changed my mind on
#220please don’t correct this spelling