341–350 of 704 posts
Cannot agree with this one. For example, different indent size can be misleading and has introduced many bugs that are hard to notice during review. Apple had a security issue because of this.
Earlier quoted context omitted.
>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 w…
This is so important. PMs are there to serve management and engineering, not the other way around. As soon as you have PMs who are trying to boost their own profile, you're screwed.
> People who stress over code style, linting rules, or other minutia are insane weirdos I suspect this has to do with a combination of personal preference and never having worked with a reliable (in terms of just never changing the semantics) code formatter like Black. Sure, I don't agree with every single thing Black does, but it's still infinitely better than trying to enforce code style manually. And don't get me…
After reading these, I am wondering how anyone could've thought differently, as I agree with them all and it seems to me that to disagree with any of them doesn't seem to be reasonable. For example, typed languages are of course better than untyped ones, especially for large codebases with multiple levels of experience of the people who write them. In other words, these seem to be exactly the opinions that the majori…
> Designing scalable systems when you don't need to makes you a bad engineer.
Creating overly scalable solutions is useful for learning, especially early on. I've done this.
> Despite being called "engineers," most decision are pure cargo-cult with no backing analysis, data, or numbers.
This is true in almost every human endeavour. It's not a useful opinion. Most decisions don't matter that much so adding data is a waste of time.
> Code coverage has absolutely nothing to do with code quality
I don't buy there's no correlation between code coverage and code quality. I'd much rather take code with >80% coverage than 0 coverage. My revised take is that the value of code coverage rapidly diminishes past 80% (maybe log scale-ish). I also think code coverage metrics are not especially useful outside of library code.
> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.
Google tried getting rid of managers. It didn't work. Establishing lines of communications in large orgs is hard.
Usually i disagree with these types of lists, but this one seems pretty spot on. My only quible would be that only code quality static analysis is useful. Security static analysis on the other hand (e.g. taint analysis to find security bugs like XSS) is pretty overrated most of the time unless you work really hard to make it fit in your context. I also think linting rules are important, not for what they actually do,…
People with less experience consistently undervalue linting and code formatting and style. Code linting forces one to deal with code smells and innocuous errors that can cost a lot to fix once they escape into the field. Consistent code formatting and style are invaluable in (a) reducing cognitive load in picking names, which is a hard problem in computer science, (b) clarifying the structure of the code (you begin t…
Either the linter catches it and fixes it automatically with little to no configuration, or its not important enough to be worth the time.
> People who stress over code style, linting rules, or other minutia are insane weirdos I suspect this has to do with a combination of personal preference and never having worked with a reliable (in terms of just never changing the semantics) code formatter like Black. Sure, I don't agree with every single thing Black does, but it's still infinitely better than trying to enforce code style manually. And don't get me…
I could merge that PR as is because it seems to work, but I don’t because I don’t want to deal with those hidden bugs in 10 days on production.
> After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. This has been my gut feeling for a long time, and in the last year, I finally took the time to write down my thoughts on the topic. Every week since February 2020, I wrote about some aspect of interviewing that could be improved [0], and I now feel confident there are actionable improvements…
Earlier quoted context omitted.
There are only two options for me: MySQL or Postgres. And using AWS generally means using Aurora. Then the choice is already made. Not hard at all. Yep, my work involves heavy use of SQL and I find it better than the NoSQL insanity.
Just curious, for what reasons would you choose MySQL over Postgres?
Earlier quoted context omitted.
In the one job where standups went well, our limit was 15 minutes, for about 7 developers. > Standups are initially scheduled for the start of the development day. There's no reason it should. We did not have it at that time. If it's at a reasonable time (e.g. after all people have normally begun work), then have a low tolerance policy for those who come late. Sometimes our standups were about 5 minutes, because some…
If you don't have it at the beginning of the day, then you're putting a hard gate on flow. This phenomena is well known, and the disruption of having a scheduled event mid-workday is significantly larger than the time of the disruption. Everyone is going to fade out of their work long before and won't re-engage for sometimes after. As to scrum exposing cultural problems, maybe that's true, but in some cases scrums ar…
> People who stress over code style, linting rules, or other minutia are insane weirdos I suspect this has to do with a combination of personal preference and never having worked with a reliable (in terms of just never changing the semantics) code formatter like Black. Sure, I don't agree with every single thing Black does, but it's still infinitely better than trying to enforce code style manually. And don't get me…