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

91–100 of 258 posts

Re: What I wish I knew when I became CTO

#91

Post by wolco »

mikekchar wrote: post #85
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 find that tests pay off pretty quickly in terms of productivity -- somewhere around a week. There are a couple of caveats, though. First, you have to have a team that's already good at TDD (and not just test-after-the-fact). What I mean by TDD is hard to describe succinctly and especially since I said it's not test-after-the-fact, it's easy to think that I mean test first. I don't. To me TDD is a way of structuring…

tdd can be faster for some but you are forced into a funnel that involves another step.

If you know exactly what you are writing it is quicker to add your changes jump to the next file add your changes. If you are constantly checking the browser to see if what you wrote works Tdd can help.

Re: What I wish I knew when I became CTO

#92

Post by latch »

wolco wrote: post #86
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…

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.

Re: What I wish I knew when I became CTO

#93

Post by derefr »

darkerside wrote: post #82
derefr wrote: post #28

Earlier quoted context omitted.

Are you sure they really have any more meaning, or are you just ascribing them meaning that exists more in your "evaluation context" than in the text itself? Compare: the way meditation is usually taught. There is something "there" to communicate, but meditation teachers mostly fail to communicate it. To use an old phrase, they are "pointing at the moon"—but, to stretch the analogy a bit, they're doing this pointing…

What is up with the disrespect I constantly hear for wordless understanding? Not everything is best communicated verbally. There's a reason traditional education is often described as a series of falsehoods.

There's nothing wrong with wordless understanding per se; the thing that's "wrong" is thinking that you have words (i.e. a teaching) that can effectively, repeatably communicate a concept, when you actually just have a wordless understanding.

The problem of meditation teaching is false positives: people experience enlightenment while pondering some koan, so they think that that koan actually helped, and pass it on. It's superstition. Anything could have helped. Something that truly helps, should help more people than average, more often than chance—and if you've got that, you've got words.

Re: What I wish I knew when I became CTO

#94

Post by kaeawc »

wolco wrote: post #86
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…

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 then of course it will always feel like that. When estimates include that stuff and you show product you can ship features more reliably more often in the long run, they buy into that. If they don't buy into that they are either very delusional, have only worked with absolutely perfect people, or they utterly do not care how many extra hours / stress the lack of quality causes you / the team / the company.

Re: What I wish I knew when I became CTO

#95

Post by NickBusey »

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.

This article seems focused towards startups, and the chances of most startups even having a tech lead/architect are pretty slim. So yes. Many CTOs do pretty much 'everything' for quite a while until the funding is there to build a real team.

Re: What I wish I knew when I became CTO

#96

Post by WhitneyLand »

What always stands out about startup reflections like these is how utterly undefined, freeform, and rapidly evolving the roles can be.

The old fire hose saying is true, but it’s not just that you’re drinking from a fire hose, it’s that you often don’t know what’s coming out of the hose next. One minute deep technical decisions, the next minute helping to establish hiring philosophy, and cashflow and growth always on a background thread.

After a few years of this I think my experience is not uncommon. If you exit and through whatever circumstance (success or failure), come back inside an F500 company, you realize that trial by fire has force fed you a vast amount of new skills without even realizing it.

On one hand, the realization is really empowering, the realization you feel comfortable taking on various high impact tasks without much thought that you could have never jumped right into before. On the other hand, it can feel limiting, because F500 companies tend not to encourage even the most talented technical people to cross roles and help define company wide hiring practices.

It’s an invaluable education, but I don’t know if MBA is quite the correct ananlogy, not sure what a better comparison is.

Re: What I wish I knew when I became CTO

#97

Post by siliconc0w »

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 few months, AND you need your most sr. engineers to help interview so that is time they aren't writing features when you're trying to hit that critical milestone.

* Don’t hire someone to do something you’ve not yet figured out

This is probably also a mistake as software engineering has become pretty specialized. Specialized Frontend, Devops, or Data engineers can bang out solutions even a strong generalist would take ten times longer to even approximate (and most likely anything they build will be throw-away). There is huge low hanging fruit in engineering productivity /business value to getting at least a decent 80% solution for most of these areas that it's worth hiring at least one strong specialist to help Shepard development.

Re: What I wish I knew when I became CTO

#98

Post by [deleted] »

Rapzid wrote: post #73
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…

How many tests does a PR need? One? Five? When would you not write tests for something(that something not necessarily being a PR, but maybe a unit or feature)? Tests, like any process, should be serving you and your goals.. You shouldn't be serving your processes or testing practices. This sort of un-nuanced thinking isn't indicative of a high performing startup or CTO IMHO. Perhaps your policies are not directly ind…

[deleted]

Re: What I wish I knew when I became CTO

#99

Post by ereyes01 »

Rapzid wrote: post #73
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…

How many tests does a PR need? One? Five? When would you not write tests for something(that something not necessarily being a PR, but maybe a unit or feature)? Tests, like any process, should be serving you and your goals.. You shouldn't be serving your processes or testing practices. This sort of un-nuanced thinking isn't indicative of a high performing startup or CTO IMHO. Perhaps your policies are not directly ind…

I guess it might sometimes be fine to be a relativist and write off the need for tests as a result of "nuanced thinking," but I think you have to accept that you are running a risk by shipping untested code into your product.

As others have said, line coverage is a misleading metric. Ideally, your tests would fully cover all _program states_, and even 100% line coverage doesn't guarantee full state coverage. If you have untested states, then the following facts are true:

- You don't have a formalized way of modeling or understanding what will happen to your program when it enters an untested state.

- You have no way to detect when a different change causes that state to behave in an undesired way.

So the answer to how many tests does a PR needs- as many as needed to reduce your software's risk of failure to a minimal level... And this is failure right now, and in the future, because you will likely be stuck with this code for a while. Since it's difficult to know how much a future failure will cost your company, IMO I always try to err on testing as much as possible. Plus, good comprehensive tests have other benefits, such as making other changes / cleanups safer by reducing the risk that they unintentionally side-effect other code.

Re: What I wish I knew when I became CTO

#100

Post by brett40324 »

geofft wrote: post #57
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 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 reply on HN