11–20 of 59 posts
What exactly would be the audience for this? I’d be worried about someone coming in as a CTO who would actually need a list like this.
The more experienced you are, the more you realize how little you know.
I like that it's short and somewhat curated, try to make it stay that way. Most awesome lists grow to be link dumps. For instance the awesome-js is over thousands lines long now, containing all sorts of random crap. It can be nice as a way to know what's out there, but when it contains 40 mvc alternatives in addition to react/angular and other big ones, it's just not useful.
My biggest challenge as a CTO is that, by nature, I'm singular in focus. If I am developing something I find it hard to context switch and review other developers' work. The best strategy I have found so far is to block certain times in the week solely for reviewing everyone's progress.
What exactly would be the audience for this? I’d be worried about someone coming in as a CTO who would actually need a list like this.
I, on the other hand, would be worried when a CTO claims (s)he knows everything already. The more experienced you are, the more you realize how little you know.
Ultimately, reading the material on these lists is a very small fraction of the job. Personally, I've already read most of the items on the last list years ago when I was earlier in my career and wanted to understand different historical organizational models. That's the right time to read this kind of stuff, because you can use it to pattern match and dig into what others around you are doing in an environment where you are not on the hook for their strategic mistakes.
By the time you're actually doing it, this material will probably not be that much help. You'll be in the driver's seat, not the passenger's seat. You'll need to use driver's seat tools, not passenger's seat tools.
What exactly would be the audience for this? I’d be worried about someone coming in as a CTO who would actually need a list like this.
But I still need to sometimes also do what a CTO would do in a bigger company, and if things go well and the company grows I may need to incrementally learn more and more of the themes above (up to the point where I hire a CTO to replace me in that role I guess).
Quite a few articles by Joel Spolsky but missing what I believe to be his most important, Things You Should never Do, Part I. [0] [0] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Nowadays we don’t just rewrite from scratch - we create entirely new languages to rewrite IN.
What exactly would be the audience for this? I’d be worried about someone coming in as a CTO who would actually need a list like this.
The secret to getting good at management is to acknowledge that it is a huge, deep and learnable set of skills. The best managers I know are the ones who constantly seek to improve their skills, and "do the work" to improve.
My biggest challenge as a CTO is that, by nature, I'm singular in focus. If I am developing something I find it hard to context switch and review other developers' work. The best strategy I have found so far is to block certain times in the week solely for reviewing everyone's progress.
I'm interested in hearing more about the idea of being an effective CTO while focusing on also being a developer. I imagine it's necessary for small companies, possible for growing companies, and eventually impossible for sufficiently sized companies where the CTO role is at least 40 hours of your week.
Also as someone nearing his late 30s I'm sometimes surprised how good some programmers are as young as late teens/early 20s! These rare talents mostly need me to prevent them from going into rabbit holes but when they are pointing in the right direction can produce amazing results.
I am sure my time is better spent helping a few of these do better than what I'd get from just myself programming directly in the same amount of time (management is a multiplier on the team's productivity and that multiplier can easily get smaller than 1.0).
I like that it's short and somewhat curated, try to make it stay that way. Most awesome lists grow to be link dumps. For instance the awesome-js is over thousands lines long now, containing all sorts of random crap. It can be nice as a way to know what's out there, but when it contains 40 mvc alternatives in addition to react/angular and other big ones, it's just not useful.
What exactly would be the audience for this? I’d be worried about someone coming in as a CTO who would actually need a list like this.