> Designing scalable systems when you don't need to makes you a bad engineer.
Oh no. He is 100% correct. Also I am a bad engineer.
Software engineering topics I changed my mind on
641–650 of 704 posts
Re: Software engineering topics I changed my mind on
#642Earlier quoted context omitted.
I am a veterinarian and recruiting is way more straightforward. You’re not going to test the person on the spot. It’s way more about personality fit, what you like/dislike to do, and where you see yourself a few years later down the road. And then a real paid tryout. Also I just changed jobs and was able to write code quickly because they were recruiting with tasks in mind for me. Sometimes it feels like the position…
1. “I am a veterinarian and recruiting is way more straightforward” 2. “Also I just changed jobs and was able to write code quickly because they were recruiting with tasks in mind for me.” Is no one else confused by this? How common is a coding veterinarian and why do veterinarians write code?
I just took it to mean they were a veterinarian and now they work as a programmer.
Re: Software engineering topics I changed my mind on
#643> 90% – maybe 93% – of project managers, could probably disappear tomorrow to either no effect or a net gain in efficiency.
I don't know how 6 years of experience in the industry can confirm this but nonetheless, I do agree that indeed there are software engineering teams that don't need, perhaps even impeded by, PMs but I think they are fewer than average. I would agree if the numbers are reversed, i.e. 7-10% PMs are not needed.
Many developers love to hate on PMs but I think most teams overestimate themselves and think that they're mature and self-managing enough to not need a PM. It can be true that the individuals in the team are self-managing on their own but it's different when it's scaled to a whole team.
For example, it's difficult to finalize a decision when most experienced and opinionated team members have differing opinions. A PM serving as an arbiter can help resolve this deadlock. (Yes, there are strategies out there on how to make decisions w/o an arbiter but then, how do they decide which strategy to use?)
Re: Software engineering topics I changed my mind on
#644Earlier quoted context omitted.
> 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 p…
What is the upside of a higly diversified worksforce? Where I work we're all white males age 20-60 except accounting, they're white females around age 30. What's bad about this? What value does it bring to diversify, what should we look for and why is it important? Or are we too small to need diversifying yet with only about 30 employees?
This is a question I wrestled a lot with. Growing up, diversity was not something I thought a lot about, and in any case I have always considered myself a hard-nosed type of thinker, for whom concerns about quality and the bottom line should _always_ outweigh the messy questions of identity politics.
But these days I work at a much more diverse organization than the one in which I started my career and what I have realized is: it's better. Better teams, better business, better tech. Far from being a sop to some sort of social-justice party line, diversity in the workforce has made every member function at a higher level.
Social science research has pretty clearly shown that more diverse organizations tend to be more profitable ones, and my own experience confirms this. I don't know the mechanism by which diversity brings this improvement about, but I have two theories as to possible contributing factors:
1) Diversity (at least intellectual diversity) forces us to defend our ideas. Homogenous groups in all pursuits tend to mistake their own way of doing things for some sort of iron law of the universe. Diversity can impose intellectual humility on members of the group and is a useful counter to our tendency to cargo-cult.
2) We pattern-match too aggressively in our evaluation of candidates, which leads us to inadvertently underrate people who don't match the pattern of the type of person we are used to thinking of as being competent. On HN, we talk about this all the time in terms of the software industry's folkloric approach to interviewing.
Re: Software engineering topics I changed my mind on
#645I 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?
For me, one of the virtues of pencil and paper is that I can go outside, sit under a tree, and think. I think differently there than I do in my cube. I can't describe exactly how I think differently, but I do. Some problems are easier to think about there (and some aren't).
Re: Software engineering topics I changed my mind on
#646Earlier quoted context omitted.
Re-inventing the wheel can be useful for learning, but can have very real costs, often in the form of production outages. * "You can usually use user metadata field X for billing" - except for those users for whom field X actually maps to something else, for tech debt reasons. (Is it stupid and bad? Yes. Is anyone going to be able to fix it this year? No. Is this going to result in Very Big Customer TM getting mad? Y…
> often in the form of production outages Completely unrelated. If you have production outages resulting from new code you have serious gaps in your certification process, especially so if the new code covers existing process/requirements. You are probably insecurely reliant upon dependencies to fill gaps you haven’t bothered to investigate, which is extremely fragile. The benefit of code reuse is simplification. If…
> If you have production outages resulting from new code you have serious gaps in your certification process
If you have production outages every week, yeah. But no organization is free of production outages. When they do happen (I said when, not if) it matters a lot if you used standard libraries, code that is plugged into the infrastructure, and the like, and not hand-rolled cowboy code
Re: Software engineering topics I changed my mind on
#647Stick with languages, tools, and techniques that respect the math theory. Category theory, type theory, set theory, relational algebra, 1st order predicate calculus, 2nd order predicate calculus. The OP has intuitively gravitated to this side. Theory isn't going to have an answer to every question, just don't willfully oppose it. Everything else (best practices, fads, etc.) is a convention at best, sometimes useful,…
Not having a formal cs background, the comments on HN that wax about predicate calculus and algebras always raise questions for me.
Is it a higher plane of programmer thinking or just abstract technical jargon and ideas that are suited for hard core technical cs research but bear little value in practical programming tasks?
Like knowing the Latin names and full phylogenic tree and exact relation of humans to the animal snuffling outside when all most people need to know is whether it’s a small animal like a raccoon or is large like a grizzly bear.
Like in the course of writing a feature engineering pipeline, tuning a ML model, and then deploying it as an api or as a scheduled batch predictor for another pipeline, at what point should one start thinking of parts of this in terms of “1st order predicate calculus” during the day to day tasks?
At what point in working on a feature card does someone generally think of relational algebra?
What tools don’t respect these things? What will happen by using them?
Like can anyone give an ELI5 of the day to day use of explicitly using these concepts to guide average programming tasks?
Re: Software engineering topics I changed my mind on
#648Earlier quoted context omitted.
What is the upside of a higly diversified worksforce? Where I work we're all white males age 20-60 except accounting, they're white females around age 30. What's bad about this? What value does it bring to diversify, what should we look for and why is it important? Or are we too small to need diversifying yet with only about 30 employees?
It depends. I’m famously non-PC, but there are certainly scenarios where diversity is actually a large benefit. If you are making a product, it makes sense to have a diverse team working on it so that it had the broadest appeal or usability- Apple Watch not identifying the heart rate of black people and the Facebook image identifier misclassifying black people as monkeys being the most famous or prominent examples.
> Apple Watch not identifying the heart rate of black people
Do you have a credible source for this claim? The one I found—from 2015 [1]—corrected the bit about skin color in their reporting but retained the bit about how Apple Watches can fail to work due the kind of pigment typically used for tattoos.
Perhaps you misremembered and should have mentioned Fitbit [2]?
1: https://qz.com/394694/people-with-dark-skin-and-tattoos-repo...
2: https://www.statnews.com/2019/07/24/fitbit-accuracy-dark-ski...
Re: Software engineering topics I changed my mind on
#649It’s interesting, I think, how many people this resonates with. Why do people enter the software business with such strong beliefs about topics like this that after a few years they realize they were wrong?
Because universities have teachers that haven't spent six years in industry to learn these things, and they pass on their unsupported-by-real-world-experience ideas to their students.
Re: Software engineering topics I changed my mind on
#650Here'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…
First time I have every heard of "detroit-style" TDD (and from looking it up "London-style"). Why were they given these names?
This article explains it: https://medium.com/dev-genius/detroit-and-london-schools-of-...