What I wish I knew when I became CTO

Post by nine_k » Wed, Feb 14, 2018, 4:29 AM UTC

bowlich wrote: post #77

apocalyptic0n3 wrote: post #23

Earlier quoted context omitted.

I'm not a CTO but I do lead the dev team at our agency (was previously 16 devs, but we've slimmed down to 7 currently). I want to preface this by saying that at an agency, your biggest enemy is always time; sales teams have to sell projects for the absolute minimum in order to get a contract, so you can't waste time on non-essentials for most projects. That said, the biggest resistance I have found is "this feature i…

I remember my agency days. Now days I work on a single long-running legacy project where tests make sense. Back then, I read a lot about how testing was the "right thing to do." But I also realized that most of the time (a) the client wasn't going to be willing to pay for the tests and (b) odds are that once we launch the product, that will be last time I ever look at it. Maintenance will occur in five years when sal…

Post by senoroink » Wed, Feb 14, 2018, 4:31 AM UTC

tomnipotent wrote: post #108

senoroink wrote: post #78

It's funny you mention that you had difficulty having your team write tests. At my company, the CTO has difficulty writing tests and the team has consistently written adequate test coverage. I fixed this in a new project by starting with jest [1] and failing the CI if the test coverage wasn't at 100%. [1] : https://facebook.github.io/jest/

> failing the CI if the test coverage wasn't at 100%. This is horrible advice and should never be followed.

Post by geofft » Wed, Feb 14, 2018, 4:35 AM UTC

brett40324 wrote: post #100

geofft wrote: post #57

Earlier quoted context omitted.

> If tests can not be written easily for a class, it has to be refactored. How do you make sure that the refactored class does the same thing as the old one? Rewriting old code that you don't have test coverage for is way riskier than whatever small change you were going to make to it. I write a lot of code without tests because a lot of legacy codebases aren't set up to be testable, but they work , and it's importan…

> How do you make sure that the refactored class does the same thing as the old one? This. This is the problem. The answer, with tests.

Post by tinymollusk » Wed, Feb 14, 2018, 4:43 AM UTC

redler wrote: post #9

ripberge wrote: post #2

Enjoyed reading this article, all valid points. However, the one thing that stood out to me in this area was how light I was in effective principles of management and leadership. As a CTO of an organization of more than a handful of people you eventually "get things done" largely via other people rather than being hands on yourself. Had to read a lot of Harvard Business Review to gain the skills and confidence for th…

It’s funny how, as you progress through a career and gain responsibility, those HBR articles go from seeming like a bunch of Markov chain corporate-speak to being on-target for that exact problem you had last month with the leadership team.

Post by tinymollusk » Wed, Feb 14, 2018, 4:45 AM UTC

ecshafer wrote: post #117

speby wrote: post #110

Earlier quoted context omitted.

In a word, no. But in startup-land, where the total number of people on the engineering team is, say, less than 10, chances are good that the CTO will also play a lead engineer and/or architect sort of role, in which case they will play a part in designing the architecture, selecting frameworks, and so forth. CTO of, say, US Foods? No, of course not.

Why call the role a CTO then? If the role is closer to a tech lead or architect, just call them an architect. This has always confused me in start up land. There will be a full c suite in a company of 10 people, despite that those c suite folks day to day would look nothing like a corporate position. Just call it what it is instead of inflating titles.