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

111–120 of 258 posts

Re: What I wish I knew when I became CTO

#111

Post by mratzloff »

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 the code review process, and use it as an opportunity to educate about what makes a good test. Make it part of the performance review and tie raises to it (and, if it goes on long enough, continued employment).

Need to write tests for existing untested areas of the code? Have the team create a developer rotation so they dedicate someone to it for part of each sprint.

Re: What I wish I knew when I became CTO

#112

Post by clay_to_n »

hartator wrote: post #8

> Don’t hire someone to do something you’ve not yet figured out Hum. I would say the reverse. Bring people that are smarter and know more than you.

Both points are true:

Don't hire a role you think you need until you're sure you need it. Sometimes startups think "we need an HR person" or "we need a marketing person" before those jobs are actually at the point where they require a full-time person.

But after your first few engineering hires, you will probably know well whether you need, say, a backend engineer. You will have people doing some of that work, and be able to look at your roadmap and estimate correctly.

But for first-of-their-type roles (like my marketing or HR examples), that's harder - often part of it is startup leadership thinking "we could be doing so much XYZ I don't know about", instead of "we're doing 10 hours of XYZ a week and I know we need 40".

Once you've decided you need the hire, you want to get a person as smart as possible.

Re: What I wish I knew when I became CTO

#113

Post by dionian »

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 do cost time, but an investment in an automated test can save orders of magnitude greater time than it takes to write them... in the end, automated tests save a lot of time, as long as they (A) cost relatively little to maintain and (B) provide a reasonably useful guarantee of quality

Re: What I wish I knew when I became CTO

#114

Post by nine_k »

wolco wrote: post #106
kaeawc wrote: post #94

Earlier quoted context omitted.

> 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.

The problem is that the "bad culture" wastes more time and mental strain on addressing the consequences of the lack of tests than it would spend maintaining a proper test suite.

This waste exhausts morale.

Re: What I wish I knew when I became CTO

#115

Post by latch »

leoc wrote: post #105
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...

The genesis for The Mythical Man Month:

"In particular, I wanted to explain the quite different management experiences encountered in System/360 hardware development and OS/360 software development. This book is a belated answer to Tom Watson's probing questions as to why programming is hard to manage."

Re: What I wish I knew when I became CTO

#116

Post by twblalock »

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 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 point of view, as it would be if none of the engineers wrote tests.

At my current company, test coverage is taken seriously as a job requirement, and it is considered during performance reviews. Consequently, the test coverage is pretty darn good.

Re: What I wish I knew when I became CTO

#117

Post by ecshafer »

speby wrote: post #110
dpeck wrote: post #88

Earlier quoted context omitted.

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.

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.

Re: What I wish I knew when I became CTO

#118

Post by coupdejarnac »

leoc wrote: post #105
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...

Anecdote time. My former company outsourced embedded development to the company that does firmware for Toyota. It was a complete disaster, and a year of work had to be scrapped. Code was rife with cut and paste, badly reimplemented mutexes when they could have used the ones supplied with the RTOS, and other nonsense. I suspect the Japanese company put all their deadweight engineers on the project.

Re: What I wish I knew when I became CTO

#119

Post by nine_k »

siliconc0w wrote: post #97

So hiring is pretty hard but I kinda disagree with most of the points there.. * only hire when desperate Strong talent is so hard to get you should probably always be hiring. If you're hiring too many people your bar is probably too low. * only hire to keep up with growth You need to be at least a little preemptive. The hiring process itself can take months, plus the time to train even good new hires is at least a fe…

This is good advise when you have a lot of money to spare. Startups sometimes are more strained.

Re: What I wish I knew when I became CTO

#120

Post by piotr001 »

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 CTO at a bootstrapped agency that has now 30+ ppl, and I couldn't agree more with the author.

Sure thing that you can use your authority to force ppl, but should you?

Smart people are hard to come by but once you have them you should let them work, and when you tell them how to do their job you implicitly assuming that you know better. Besides if you force them you achieve nothing but some brain-dead tests that are going to hunt you later and getting a budget to "rewrite tests" is a fairytale.

The art here is to build a culture that embrace the test as a powerful tool. So newcomers are quickly seeing benefits and start to write the tests in right places, not for the sake of an artificial metric.

Besides, there are plenty of places where having high coverage is going to be a waste of time: - throwaway prototypes, - heavy UI code full of animations - they need to look right that is hard to test, - infrastructure code if you have just a few servers of a particular type, - customer projects with unreasonable deadlines that are not going to be touched again,

So having your team that writes tests is a hard job and using PR policy won't help much.

The things that worked for me were: - write tests that make sense your self in early stages of the project - pair with your employees and write tests with them, - do peer reviews and suggest what could be tested and why it make sense.

Post reply on HN