What I wish I knew when I became CTO • Hacker News Board

Re: What I wish I knew when I became CTO

#131

Post by hota_mazi » Wed, Feb 14, 2018, 4:53 AM UTC

> I appreciate now that technologies have a surprisingly short lifespan

That's pretty much only true in the Javascript ecosystem. Every other areas of the technological stack usually see lifetimes in the decades.

> Stepping aside from pure technical decisions, the life-blood of being a CTO is people management

Not really, no. That's the job of a CTO at a start up, not at a larger company. I'm not sure the author of the article has actually learned the right lessons from his experience.

At the end of the day, CTO of a start up is not really a CTO role in my opinion. It's a technical co founder. You just happened to be the most senior person of the team at a point in time and you inherited a few leadership responsibilities in the process.

I've seen a lot of start ups fail because they fail to recognize that fact and didn't realize that after a few years, they needed a different CTO than the co founder, someone who understands that role at scale and the many tasks it implies that are not necessarily relevant to the early years of the company.

Re: What I wish I knew when I became CTO

#132

Post by threeseed » Wed, Feb 14, 2018, 4:53 AM UTC

latch wrote: post #92

wolco wrote: post #86

Earlier quoted context omitted.

If there is never enough time to refactor and new features are always being pushed when does anyone have time to write new tests. Tdd helps focus and structure some developers but rarely does it save time. In situations where everyone is being pushed too hard for too long saving time is more important. I would bet documentation is also a low priority.

Tests don't cost time. Not true 100% of the time, but it's the right "default" mindset, because it's true the majority of the time.

Of course tests costs time. You are often writing twice the amount of code and there is the amount of time it takes for most CI systems to run all of the tests (often tens of minutes, but I've worked on hours).

But the reason we do it is because it increases quality.

Re: What I wish I knew when I became CTO

#133

Post by gaadd33 » Wed, Feb 14, 2018, 4:53 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.

What do you call the person running the company of 10 people? I guess "team lead" would be a non inflated title, or just "manager"? It would be pretty strange to have to explain that title to anyone outside of the company though

Re: What I wish I knew when I became CTO

#134

Post by nstart » Wed, Feb 14, 2018, 4:56 AM UTC

apocalyptic0n3 wrote: post #23

mkarazin wrote: post #13

> I’ve found it a real struggle to get our team to adopt writing tests. I find this hard to believe. Do others CTOs / team leads find this to be the case? I've been a CTO of two small startups with 3-7 developers. We've had resistance to tests at some points (myself included). We've solved it fairly simply. All pull requests (PRs) require tests. PRs are rejected immediately without tests. If a PR doesn't have tests a…

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 find this view (and the replies) interesting. One thing that I've experienced after writing tests a lot is that once you know the patterns, implementing TDD becomes effortless. Eg (python)

Need to test interfacing with an SDK correctly?

Sure, patch the SDK methods and ensure they are called with the proper parameters

Also, for extra coverage, add a long running test that makes actual calls using the SDK. Run these only when lines that directly call the SDK change (and ideally there should only be a few of those).

Need to mock a system class?

Sure - Here's the saved snippet on how to do that

---

This of course applies only if you repeatedly access projects that use the same stack. If you don't then I understand that it can be pretty hard. But basically over time, writing tests must become easier else that's a sign that something in the process is not working correctly. Knowledge isn't being transferred. Or things aren't being done uniformly.

Ideally once you get past a certain point, testing should be just a selection of patterns from which you can choose your desired solution to implement against a given scenario.

I accept that I could be missing something here so please take what I say within the context that my thinking applies to work that can be described as technologically similar.

Re: What I wish I knew when I became CTO

#135

Post by rmccoy6435 » Wed, Feb 14, 2018, 5:06 AM UTC

mratzloff wrote: post #111

latch wrote: post #65

> I’ve found it a real struggle to get our team to adopt writing tests. If you're struggling to judge the engineering culture of a company that you're considering joining, consider this indicative of a poor one. It isn't definitive, but it's something you should ask about and probe further. Ask to see their CI dashboard and PR comments over the last few days. When they talk about Agile, ask what _engineering_ techniq…

This stems from an unwillingness to make it a job requirement. There are several things you as a software engineer are expected to do as a part of your job: write code, write tests, participate in code reviews, ensure successful deployment, work effectively with various groups, etc. It's really simple: state the job requirements up front in the position description and during the hiring process. Make testing part of…

I'm in 100% agreement with you up until the point of tying your test coverage and writing of tests to your employment. In my eyes that promotes a culture of writing bogus tests that provide no value other than to make more green check marks. You should be encouraged to write tests by your colleagues and be in a culture that sees the benefits, rather than forcing people to do it.

I'm also unsure if sitting one developer down in a corner for a segment of each sprint and dedicating them exclusively to testing legacy code with no purpose is valuable. You should be testing legacy code as you come across it and making sure you harness it properly and make your modifications and continue to the next stop. If you are spending time doing something that doesn't complete a bug or a feature, you're spending valuable time on testing something that may completely removed in the future.

Re: What I wish I knew when I became CTO

#136

Post by bkeroack » Wed, Feb 14, 2018, 5:10 AM UTC

latch wrote: post #92

wolco wrote: post #86

Earlier quoted context omitted.

If there is never enough time to refactor and new features are always being pushed when does anyone have time to write new tests. Tdd helps focus and structure some developers but rarely does it save time. In situations where everyone is being pushed too hard for too long saving time is more important. I would bet documentation is also a low priority.

Tests don't cost time. Not true 100% of the time, but it's the right "default" mindset, because it's true the majority of the time.

Tests absolutely cost time, inversely proportionate to the raw ability of the programmer. A 95th percentile engineer can write cowboy code with zero tests that largely works. Enforcing tests could cause up to a 50% slowdown. It’s probably worth it in the long run, but for a time and cash strapped startup its a legitimate cost/benefit analysis.

Re: What I wish I knew when I became CTO

#137

Post by yeukhon » Wed, Feb 14, 2018, 5:13 AM UTC

mbesto wrote: post #66

Much of this is summed up to be: CTO positions are much more about technology vision (e.g. choosing frameworks/technologies that can last + serve your needs today and tomorrow) and hiring/retaining talent. Everything else is gravy.

It depends on the companies. For some, CTO is merely a business title and an outward facing person, but the (S)VP of Engineering / Director of Engineering is more politically powerful since he/she leads the engineering division, and does not report to CTO at all.

Many of the Fortune 500 companies have both CIO and CTO, and they are not necessarily peer to each other. In the recent years a bunch of new titles like big data chief, digital media /innovation chief, process and technology chief, etc which make the political scheme more confusing and toxic. Many of them end up reporting to CEO directly. There's also EVP rank, so go figure...

Again, it depends.

Re: What I wish I knew when I became CTO

#138

Post by snowwrestler » Wed, Feb 14, 2018, 5:13 AM UTC

threeseed wrote: post #132

latch wrote: post #92

Earlier quoted context omitted.

Tests don't cost time. Not true 100% of the time, but it's the right "default" mindset, because it's true the majority of the time.

Of course tests costs time. You are often writing twice the amount of code and there is the amount of time it takes for most CI systems to run all of the tests (often tens of minutes, but I've worked on hours). But the reason we do it is because it increases quality.

I think the theory is that increasing quality will save time in the long run via fewer regressions and bug reports.

Making that math work, though, seems to depend on the idea of some sort of future crisis state, where normal development is slowed way down. (You'd need to avoid a big slow down in the future, in order to balance out the continuous extra time given to testing.)

Does such a crisis lurk in the future of every development effort? Hard to know. It's certainly not the only way technology projects fail. Plenty of products have passing tests but fail to find customers.

Re: What I wish I knew when I became CTO

#139

Post by lilbobbytables » Wed, Feb 14, 2018, 5:19 AM UTC

twblalock wrote: post #116

mratzloff wrote: post #111

Earlier quoted context omitted.

This stems from an unwillingness to make it a job requirement. There are several things you as a software engineer are expected to do as a part of your job: write code, write tests, participate in code reviews, ensure successful deployment, work effectively with various groups, etc. It's really simple: state the job requirements up front in the position description and during the hiring process. Make testing part of…

I couldn't agree more. I've worked at places where some of the engineers were conscientious about writing tests and having excellent test coverage. Guess what? Our services were still unreliable because the engineers who didn't write tests brought poor quality into the codebase, so we had constant problems. Even a few engineers on the team who don't write tests can make the product as unreliable, from the customer's…

Per your previous now on reliability, does reliability at the current company match the test coverage?

Re: What I wish I knew when I became CTO

#140

Post by robotpony » Wed, Feb 14, 2018, 5:38 AM UTC

mkarazin wrote: post #13

> I’ve found it a real struggle to get our team to adopt writing tests. I find this hard to believe. Do others CTOs / team leads find this to be the case? I've been a CTO of two small startups with 3-7 developers. We've had resistance to tests at some points (myself included). We've solved it fairly simply. All pull requests (PRs) require tests. PRs are rejected immediately without tests. If a PR doesn't have tests a…

I've never found developers resisted reasonable unit tests, though teams may squabble about what _real_ unit tests are, or may have been burned by poor approaches to unit testing in the past. If you can find the cause of resistance, all teams I've worked with have been happy (even excited) to get better testing in place. It makes them more productive and more successful when done properly.

What I find more common is for the business to be unprepared to make lateral changes to a product. Even rational unit tests are a medium term investment. You need to spend time developing features customers don't see, and apply those tools for some time, to see quality differences. That can be difficult to justify in a number fairly normal business scenarios (low cashflow/reserves, high tech debt/regret, etc.).

To help offset the cost (and delayed benefits), I've always suggested phasing in unit test strategically. Pick a module or cross-section of the product that is suffering from bugs that customers see (i.e., affecting revenue) and add the minimum viable tests to that. Repeat as needed, and within months/years, you'll have coverage that fits the business needs well.