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

51–60 of 258 posts

Re: What I wish I knew when I became CTO

#51

Post by jeroen »

Swizec wrote: post #44
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…

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.

Some options:

- Educate your CTO.

- Just start writing tests. Consider whether you can pull this off.

- Wait for something to go wrong where tests would have caught the problem earlier. That would be a good time to bring testing up again.

- Find another job.

Re: What I wish I knew when I became CTO

#52

Post by saalweachter »

k_sh wrote: post #37
thrrr wrote: post #15

If your engineers don‘t write tests you hired the wrong people. Testing is vital. Make a rule: Every change needs to be tested (you can even set up a pre-commit hook for this. If a class has no test, one has to be written. If tests can not be written easily for a class, it has to be refactored.

> If your engineers don‘t write tests you hired the wrong people. Disagree - if your engineers don't write tests, you need to clearly state to them that tests are table stakes, and create an environment conducive to the outcome you want (set up CI, make it fast, set aside time for test-writing hackathons). If your engineers don't want to _follow_ that leadership after it's given, then yeah, you hired the wrong people…

If your engineers don't write tests, it also probably means that they are not being rewarded for writing tests or punished for not writing tests; indeed, if they are rewarded for doing things that are not writing tests (such as pushing new features) and they can do those things without writing tests, they are being rewarded for not writing tests.

Just telling engineers, "write tests" and then promoting the ones that don't is bad leadership: you need to create an environment where the behaviors you desire are the ones that are promoted.

Re: What I wish I knew when I became CTO

#53

Post by jnordwick »

reilly3000 wrote: post #22
bpicolo wrote: post #16

Earlier quoted context omitted.

Definitely the kind of thing you use a dedicated replica for

Really not a replica. That is a fine shim for early days but it means you are severely limited to what you can do with reporting based on the data structure prod has. A better pattern is prodDB->Kafka/kinesis streams to a reporting DB like redshift/snowflake/big query. That way you can shape the data however you need, and it lets data teams avoid bogging down engineering.

> prodDB->Kafka/kinesis streams to a reporting DB like redshift/snowflake/big query

Over engineer much? I've worked at trading and advertising analytics firms that had less engineering

Re: What I wish I knew when I became CTO

#54

Post by zeeshanm »

I like reading posts like this one. May be they serve as a form of therapy for me that I’m not in this alone. There are others in a similar boat, fighting the good fight, making similar mistakes, and having the same realizations.

Very well; now, I can go back to work with my head up high. :)

Re: What I wish I knew when I became CTO

#56

Post by laythea »

thrrr wrote: post #15

If your engineers don‘t write tests you hired the wrong people. Testing is vital. Make a rule: Every change needs to be tested (you can even set up a pre-commit hook for this. If a class has no test, one has to be written. If tests can not be written easily for a class, it has to be refactored.

I'm not sure what kind of professional environment you work in but I would argue that the activity of testing is separate to the activity of writing tests, and that, writing tests only forms part of that.

Re: What I wish I knew when I became CTO

#57

Post by geofft »

thrrr wrote: post #15

If your engineers don‘t write tests you hired the wrong people. Testing is vital. Make a rule: Every change needs to be tested (you can even set up a pre-commit hook for this. If a class has no test, one has to be written. If tests can not be written easily for a class, it has to be refactored.

> 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 important to the business that we're able to deliver small bug fixes and incremental improvements on the existing code while we write whatever replacement system we want to write. As I work on them they'll slowly get more testable, but if you're abandoning working code because it has no tests, you're usually making the wrong decision. (Which the author recognizes.)

Re: What I wish I knew when I became CTO

#58

Post by laythea »

staunch wrote: post #10

> ...it’s a blessing that my predilection for hipster technologies has not caused any serious problems. It's entirely possible that this was the primary source of his problems with hiring, firing, testing, and a lot more. The technology you choose determines which technologists you attract. And it's not a superficial thing, it actually says everything about the CTO's own technical skill, judgement, and experience.

Couldn't agree more. It does not seem like a wise thing to do.

Re: What I wish I knew when I became CTO

#59

Post by cyberferret »

> "I appreciate now that technologies have a surprisingly short lifespan"

This fact alone makes me so glad that I stuck with older tech that has withstood the test of time for our own SaaS. I know that we have users from bleeding edge tech companies sign up for our service, then run away when they glean the 'ancient' tech that it runs on - but then again, I think we have outlasted many other new tech frameworks/languages that have rocketed on high, then fizzled out into obscurity in that same time.

Re: What I wish I knew when I became CTO

#60

Post by jedberg »

thrrr wrote: post #15

If your engineers don‘t write tests you hired the wrong people. Testing is vital. Make a rule: Every change needs to be tested (you can even set up a pre-commit hook for this. If a class has no test, one has to be written. If tests can not be written easily for a class, it has to be refactored.

> If your engineers don‘t write tests you hired the wrong people.

That's great if you have the luxury of time.

Good test coverage will definitely save you time in the long run, no doubt about it. But it will cost you dearly in the short term.

And if your company's life or death hangs on getting a feature out a couple days sooner, then skipping tests is a perfectly valid thing to do.

Post reply on HN