Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I wish I knew when I became CTO

medium.com

Post reply on HN
Print view View original

101–110 of 258 posts

Re: What I wish I knew when I became CTO

#101

Post by rootusrootus »

sidlls wrote: post #87
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…

Team Lead/Manager here. I frequently have the opposite problem: people who think code coverage (quantity) is as important as or worse more important than test quality. I'd much rather have low percentage high quality coverage than high-percentage low quality coverage.

I completely agree. I've met a few developers who think that 100% coverage is required, and that a complete set of tests will save them from all bugs. Perhaps unsurprisingly, they wrote pretty crap code. Passed the tests, but it was unpleasant to work with.

I like to see good coverage (say, 85%) because the act of trying to cover that much has led us to discovering some bugs that would otherwise have gone unnoticed until someone ran into them in production. But 100% line coverage is still a tiny, tiny fraction of covering all permutations of how that code is used, so I feel like trying to hit some kind of holy grail perfect coverage target over-emphasizes the value of tests. While tests can absolutely be very useful, it's the actual running code that needs to be high quality, the tests are just helpers.

Re: What I wish I knew when I became CTO

#103

Post by rootusrootus »

ghayes wrote: post #81
aianus wrote: post #76

Earlier quoted context omitted.

> How many tests does a PR need? One? Five? Enough so the overall coverage doesn't go down.

Be careful that coverage is a proxy metric to good tests. Striving for high coverage can mislead you on the quality of your tests.

On the flip side, encouraging good coverage usually ends up uncovering some bugs that might otherwise have gone unnoticed until they bit someone.

Re: What I wish I knew when I became CTO

#104

Post by cbodolus »

ryanianian wrote: post #50
Swizec wrote: post #44

Earlier quoted context omitted.

Now say I have a CTO who doesn’t like (automated) tests be cause he thinks they’re a waste of time and mostly something a type system should do for you (never mind we’re in dynamic loosetyped land). How do I introduce tests? Tried many times, always end up not getting adopted.

Do it for yourself - tell the CTO you're doing TDD to make your own process sane. It would be weird for others to object to you adding tests to your own code. Then others will see your awesome code with great coverage and no bugs in PRs and it may even catch on. Convince one or two colleagues to do it with you.

Respectfully I disagree. I’ve found that ‘talking about doing it’ will cause problems if you aren’t able to do it and hold schedule with everything else. From personal experience, for parent post, I’ve found it’s been best to implement what you can for unit tests and grow it yourself slowly or at whatever pace you are comfortable with, but set the bar high for yourself, beat it, and then maybe try to get others on board. This only holds if there is no mentor you could talk into helping you. Just personal experience. :-/ If the culture doesn’t encourage them now, announcing you will be doing it might only hinder the effort.

Re: What I wish I knew when I became CTO

#105

Post by leoc »

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…

It's aside from your point, but would that Toyota's embedded software were as good as its mechanical engineering...

Re: What I wish I knew when I became CTO

#106

Post by wolco »

kaeawc wrote: post #94
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.

> If there is never enough time to refactor and new features are always being pushed That is a sign of bad culture, both in engineering and product. Whether its starting a green-field project in a scrappy startup or building yet-another-feature for an established product if the estimates are constantly redlining everyone's available time and never giving thought to maintenance, QA, testing, code review, and testing t…

And in a bad culture other priorities can be more important. As an employee your job is to adapt and support the business. Writing tests in a culture that doesn't value the time spent is not helpful.

Re: What I wish I knew when I became CTO

#107

Post by wolco »

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.

From a pure number of keystrokes tests can add time.

If you know exactly what to write because you have done this 100s of times before tdd will slow you down.

If you are unsure of what the outcome of what you write tdd will give you training wheels and help guide you. That may make some quicker for a little while.

Re: What I wish I knew when I became CTO

#108

Post by tomnipotent »

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.

Re: What I wish I knew when I became CTO

#109

Post by krmboya »

wolco wrote: post #107
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.

From a pure number of keystrokes tests can add time. If you know exactly what to write because you have done this 100s of times before tdd will slow you down. If you are unsure of what the outcome of what you write tdd will give you training wheels and help guide you. That may make some quicker for a little while.

I find that when working in a team, tests help save time by preventing people from stepping on each others' toes, breaking existing functionality

Re: What I wish I knew when I became CTO

#110

Post by speby »

dpeck wrote: post #88
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.

Is the choosing frameworks and technologies really a thing that CTOs do? That seems like more of a tech lead/architect job to choose the right tool for the job. I could see the cto pushing back on those choices from time to time if something is being drastically over engineered but declaring what technology is being used seems like a job far below a cto.

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.

Post reply on HN