> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.
I can't agree enough.
Software engineering topics I changed my mind on
451–460 of 704 posts
Re: Software engineering topics I changed my mind on
#452Usually 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,…
We build static code analysis tools, used by companies building safety critical stuff (planes, cars,...). If you're failure mode is "there might be fatalities" over "the app crashes", this becomes really valuable.
Code quality is already quite nice, and metrics like e.g. MISRA are supported by many analyzers; but proving(!) the absence if various error classes can be handy as well.
(Disclaimer: I work on the binary analyses, not on the source code analyses; so my detail knowledge on that front is not too deep).
+1 for linting. If the code looks "the same" I find reviews much easier since I can focus in what it actually does (or fails to do), not on "decoding" it. Though nobody should freak out on minor variations.
Re: Software engineering topics I changed my mind on
#453> 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…
Eh, the second one is probably the only point I was kind of meh on. You should almost always start with an RDBMS, and it will scale for most companies for a long long time, but for some workloads or levels of scale you're probably going to need to at least augment it with another storage system.
I think, it's mostly a question of education.
Universities taught SQL for years, so everyone knows it and its edge cases.
NoSQL databases are all different AND they weren't all taught for decades.
If you put real effort into learning a specific NoSQL database and it is suited for your problem things work out pretty well.
Re: Software engineering topics I changed my mind on
#454Usually 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,…
>Security static analysis on the other hand is pretty overrated most of the time unless you work really hard to make it fit in your context.
I think the "unless" part is key here. If used correctly, it's crazy what these tools can find, and they give you a baseline of issues to analyze/fix before digging deeper.
But yes, running them blindly just to tick a box isn't very helpful.
Re: Software engineering topics I changed my mind on
#455I love it when engineers admit changed opinions!
here's a recent thread from charity majors: https://twitter.com/mipsytipsy/status/1349262816239263747?s=...
and from me: https://twitter.com/swyx/status/1349279194446876673?s=20
basically (things I no longer strongly believe or in fact did a full 180 on)
- "Time travel debugging is only for showing off in demos"
- "HSL is better than RGB because you can control hue, saturation and lightness as independent variables."
- "We should move all errors to compile time, the earlier we catch them the more productive we are"
- "React/Preact is the best paradigm to code websites."
- "Monorepos trade off contributor/bug reporter experience for maintainer convenience."
- "If you can support dark mode you might as well support infinite themes"
Re: Software engineering topics I changed my mind on
#456Almost 20 years of professional experience here: I fully agree with this list. I even want to add a few things: > Clever code isn't usually good code. Clarity trumps all other concerns. My measurement is "simple and clean" code. Is it simple and clean? No? make it so! > After performing over 100 interviews: interviewing is thoroughly broken. I also have no idea how to actually make it better. If a good developer you…
> If a good developer you know, recommends someone they worked with: It's almost an instant hire. But for the rest, yeah, it's incredibly tough.
A talk I watched recently by Ijeoma Oluo made a point I had never considered before: statistically, most people refer friends, and most friends are of a similar background, race, culture, gender, etc. It's not intentional- people aren't going out of their way to only refer people like them- but it's measurable. And those referrals are more likely to be hired (they're good people, that's why they were referred!)
Which means referral bonuses have a perverse incentive of making a company less diverse.
I don't even have a good answer to what to do about it, because you're right: referrals are a great way to hire good developers. It's just got this big worrying downside that leaves me bothered.
Re: Software engineering topics I changed my mind on
#457> 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…
Completely agree and I feel this every day.
Half of my job is split between a functional language on the backend and a class-based language on the frontend.
I have made a conscious effort to avoid shared state, but it's harder. For example, the friction of cloning objects before passing them around. Or dealing with sort APIs that sort in place.
I'm going against the language defaults while with the FP language, it feels natural.
Re: Software engineering topics I changed my mind on
#458s/best practice/good practice/g
It shows an appreciation that there may be a better practice in the reader's situation and that the writer doesn't think they know everything forevermore.
Re: Software engineering topics I changed my mind on
#459Here'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…
Agree. I also found that learning TDD rewired my brain to think top down.
So in the many cases I don't do TDD, I imagine what the top level API ought to be before I dive in and start coding.
Re: Software engineering topics I changed my mind on
#460> 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…
> “What would we give up by using a monolith here instead of microservices?”
I love that.
I think many people are loathe to "turn the argument around", and pretend they're going the other way.
For example, imagine some legacy app used by 10 people out of 10,000 is incompatible with something like a Microsoft Office upgrade.
In many organisations, the argument goes like this: "We can't upgrade to Office 2023 because StupidApp will break!"
Turning that around: "If Office 2023 was already rolled out, would you roll that back to Office 2021 just for StupidApp?"