Pretty substantial shift that simplicity in programming is much better and more achievable than I thought
This one is a bit hard to characterize, but I think over the past few months I got better as a software engineer, and finally gained enough clarity around how a bunch of stuff worked that I didn’t really understand previously (like compilers, VMs, a bunch of networking stuff, and type systems), to get a sense of where the Chesterton’s fences are in programming land that you want to keep up, and which ones you want to tear down, and I’ve overall updated more in the “if something looks really unnecessarily complicated, it is probably indeed unnecessarily complicated, and not just some hidden complexity that comes up in the implementation”. A substantial fraction of this is definitely also the result of me just looking into a lot of JS libraries, and repeatedly finding them doing really dumb stuff that could be done much simpler.
This pretty much describes my mumble-many years of increasing scope as a programmer. There is plenty of irreducible complexity around, but there’s FAR MORE accidental complexity from incorrect attempts at encapsulation, forcing edge cases into “standard mechanisms” (bloating those standards), failing to force edge cases into “standard mechanisms” (bloating the non-core systems), insufficiently abstracted or too-abstracted models of data and behaviors, etc.
It’s easy to move complexity around a system. Done haphazardly, this increases overall complexity. Done carefully, it can decrease overall complexity. Knowing the difference (and being able to push back on (l)users who are not listening to process changes that make the world easier) is what makes it worth hiring a Principal rather than just a Senior SDE.
Pretty substantial shift that simplicity in programming is much better and more achievable than I thought
This one is a bit hard to characterize, but I think over the past few months I got better as a software engineer, and finally gained enough clarity around how a bunch of stuff worked that I didn’t really understand previously (like compilers, VMs, a bunch of networking stuff, and type systems), to get a sense of where the Chesterton’s fences are in programming land that you want to keep up, and which ones you want to tear down, and I’ve overall updated more in the “if something looks really unnecessarily complicated, it is probably indeed unnecessarily complicated, and not just some hidden complexity that comes up in the implementation”. A substantial fraction of this is definitely also the result of me just looking into a lot of JS libraries, and repeatedly finding them doing really dumb stuff that could be done much simpler.
This pretty much describes my mumble-many years of increasing scope as a programmer. There is plenty of irreducible complexity around, but there’s FAR MORE accidental complexity from incorrect attempts at encapsulation, forcing edge cases into “standard mechanisms” (bloating those standards), failing to force edge cases into “standard mechanisms” (bloating the non-core systems), insufficiently abstracted or too-abstracted models of data and behaviors, etc.
It’s easy to move complexity around a system. Done haphazardly, this increases overall complexity. Done carefully, it can decrease overall complexity. Knowing the difference (and being able to push back on (l)users who are not listening to process changes that make the world easier) is what makes it worth hiring a Principal rather than just a Senior SDE.