4 ms·
I completely agree. Whether or not he's gatekeeping a bit by shitting on Go and JavaScript, and whether or not he's promoting his book about haskell. I totally
by codyb 9y ago
I completely agree. Whether or not he's gatekeeping a bit by shitting on Go and JavaScript, and whether or not he's promoting his book about haskell.
I totally agree. It's when I'm lost that I've learned the most.
I've very frequently thought of myself as overpaid, I've come to the conclusion that it is tenacity which makes me as well paid as I am.
The worst parts about being a software engineer are setting up development environments, thats a hurdle a lot of people break on before they cross over.
When it's that single fucking space that breaks your jQuery code and you can't figure out why your code isn't working, but eventually you realize you didn't put that space between the id and class, that's a hurdle people break on before they cross over.
When it's the fact I spent ten hours already this weekend building a god damn gulp file with literally zero visible results to anyone but me, thats a hurdle people break on before they cross over.
So maybe I don't agree actually, maybe I think tenacity is what allows us software engineers to do what we do, or at least to get where we are, I definitely agree that people a lot of engineers I work with are very hard pressed to break out of their defined boundaries.
I've always been that person, and I've never been that person. I always take on projects I know nothing about, but when I'm sitting there looking at a blank file I often find it extremely difficult to figure out what to do.
Reading code is _hard_. It's unbelievably hard. And languages like Go which I've never worked with promise to make it easier through their reduction in the possible pathways one might do something. Compare that to Ruby where there is literally almost always at least two different ways to write the same exact piece of code. Or compare that to C where you're literally allocating and deallocating pieces of memory for your data structures.
He is absolutely right in that
A) teaching is very hard
B) employers shouldn't expect gods gift to mankind to people to be the only people they'll hire
But in a world where the average retention rate is as low as it is, should employers invest more in us?
He's right that civil engineers go through a lot more than we do to call themselves engineers, but are they dealing with architectures frequently featuring tens of millions of interacting features (lines of code)?
So while I have come to literally no conclusion here, I wonder, is he right that doing things ends up being far more valuable than reading about them? I sort of think so because I just spent ten hours on a gulp file which will show no gains to anyone except myself, but I also read four articles on how JavaScript works at the engine level this morning and plan to apply those principles I learned both to my own code and to code reviews in the future.
At the end of the day we should all discard what is cruft to us, and learn from what is not, and it will be different for all of us.