I learned that using the collection functions on strings in Clojure is much less performant... But it doesn’t have to be my PR. It can be anybody’s."
This reveals a fundamental problem in coding. Best practices for performant code shouldn't require ad hoc digging into PR's, and as long as it does then we'll have code that is buggy & slow(er than necessary).
Learning from others, in any field, will always be a valuable source of improvement, but it just doesn't seem that, in software dev, it results in laying down solid incremental increases in general knowledge that makes its way back into the education of future devs or current devs in a language new to them:
If this was structural engineering, you'd have to have taken a "materials" course and learn all about different types of materials, their properties, load capacities, degradation profiles and how to evaluate new ones that come your way under the same criteria.
Maybe that's what we need for software development. A structural engineer wouldn't use a composite material without knowing its performance characteristics. Why should a programmer use something like string collection from a language without knowing its performance characteristics?
This is on us to demand this, to standardize-- not languages themselves-- but the performance profiles & characteristics that we must know about in order to make a choice on which tool to use. And it shouldn't be that each user has to figure it out on their own, dig into PR's or whatever. Again, there will always be experiential learning. But too much is experiential right now.
> Maybe that's what we need for software development. A structural engineer wouldn't use a composite material without knowing its performance characteristics. Why should a programmer use something like string collection from a language without knowing its performance characteristics?
Up front, I don't disagree with you, but let me throw out a parallel benefit of your scenario here:
For the most part, in software engineering, a building won't collapse if I'm fucking around with a language and doing sub-optimal things. If I need optimization, I probably know that going in, and would probably take the time to know exactly what language/features I should use.
Since most software built today is pretty low risk/inconsequential if it fails, we might be moving the state of the art forward faster than they might in structural engineering simply because we have the freedom to fuck around and learn. We can test our materials in production, whereas I hope the dude that built my office can't. Like, yeah, definitely don't do this with medical devices and airplanes, but with CRUD app of the day, I might learn something when people decide to use it all of a sudden and it grinds to a halt.
I dunno, I should say I'm not a real software engineer in the first place and am open to being totally wrong here.
we might be moving the state of the art forward faster than they might in structural engineering simply because we have the freedom to fuck around and learn
Thanks-- I think that's a very concise response & reflection on my comment.
I still think we can & should do better, but you're right that the lower stakes probably lower the bar on acceptable crystallization of experience into best practices. Which is problematic because of things like writing a library for your own low-stakes project, but the library gets published on github and used by someone in a something that isn't low stakes.
Maybe part of what we need are defined "stakes" levels and corresponding criteria for acceptable practices at each stage.
> Maybe part of what we need are defined "stakes" levels and corresponding criteria for acceptable practices at each stage.
I think I'm going to start testing this with the TPMs and Engineers I work with. I'm going to ask a more senior TPM on my team to think about this and how it should be incorporated into our specs. My hypothesis is our engineers would be happier knowing about the risk profile of whatever failure modes we've id'ed, and they can design accordingly.
That said, I don't really work on high risk software, so this is all relative. Most of our stuff is in the "push the button again" category if it dies.
I think you read this wrong, the performance doesn't matter. It matter that the person learned something new even that he was experienced Clojure developer. And he did this by reading closed PR.
Success Open Source project are usually created by very smart and experienced developers. And big projects have a lot of them. Their Code Reviews are much better then anyone your closed source team will have, unless you're junior developer in team of Senior developers.
Right now I'm thinking that at work we also have git (for intranet application) and we have PR, this may be very good idea for newcomers to read the PR that was done to understand how some features were implemented instead of just diving into recent code. This may be best advice I've seen in a while. But maybe it's just my own idea that came from this article, that you've understand differently.
For me this article is about advice read closed PR you will learn a lot, here for Open Source projects, because OSS projects on GitHub are biggest projects you can find.
I fully agree that there is significant value in what the author writes even if there was more of the sort of crystallization of experience into learning. I just thing that this method of learning-- which seems not just useful but essential in learning how to write performant and less buggy code.
As I said, experiential learning and learning from others will always be important & valuable, as it is in any field. I just think the balance between that and more established best practices is weighted too heavily toward the "figure it out for yourself finding ad hoc sources" side of things.
> but the performance profiles & characteristics that we must know about in order to make a choice on which tool to use. And it shouldn't be that each user has to figure it out on their own, dig into PR's or whatever.
That's an interesting take – I like the idea of a catalog of standard tasks with implementations in several languages as well as their performance characteristics. I suppose Rosetta Code gets the ball rolling with this, but it's missing some performance metrics. It reminds me of Ben Hoyt's piece[1] on counting unique words in the KJV Bible in different languages.
This reveals a fundamental problem in coding. Best practices for performant code shouldn't require ad hoc digging into PR's, and as long as it does then we'll have code that is buggy & slow(er than necessary).
Learning from others, in any field, will always be a valuable source of improvement, but it just doesn't seem that, in software dev, it results in laying down solid incremental increases in general knowledge that makes its way back into the education of future devs or current devs in a language new to them:
If this was structural engineering, you'd have to have taken a "materials" course and learn all about different types of materials, their properties, load capacities, degradation profiles and how to evaluate new ones that come your way under the same criteria.
Maybe that's what we need for software development. A structural engineer wouldn't use a composite material without knowing its performance characteristics. Why should a programmer use something like string collection from a language without knowing its performance characteristics?
This is on us to demand this, to standardize-- not languages themselves-- but the performance profiles & characteristics that we must know about in order to make a choice on which tool to use. And it shouldn't be that each user has to figure it out on their own, dig into PR's or whatever. Again, there will always be experiential learning. But too much is experiential right now.