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

161–170 of 258 posts

Re: What I wish I knew when I became CTO

#161

Post by millstone »

merb wrote: post #157
fergie wrote: post #150

Earlier quoted context omitted.

To be fair, testing is to some extent an unsolved problem. The joys of testing were being extolled long before test frameworks were actually usable. Now that they are, and you can glue Travis, GitHub and the test lib of your choice together pretty easily you have solved about 30% of what needs to be tested. If, say, you are developing an Office add-in on a Mac, and you want to test it on Word 2013 on Windows 7, there…

well it happens a lot of techniques are still not understood. I mean we develop database heavy code. Should we never test the code running with the database? would be a poor choice since we would loose a lot of coverage. What we did instead were transactional tests. Which means that in PostgreSQL sense that we actually use SAVEPOINTS to actually wrap our tests inside a savepoint and than rollback to the sane state an…

Databases are ridiculously testable because your inputs are just text. What’s hard is when your inputs are platform environments and versions and hardware and racey events and...

Re: What I wish I knew when I became CTO

#162

Post by yread »

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 always find code coverage such a useless metric: if you have two independent ifs next to each other and one test goes in one if and another test in the other you have 100% coverage. Congratulations. But you've never tested what happens when you go in both

Re: What I wish I knew when I became CTO

#163

Post by [deleted] »

yread wrote: post #162
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 always find code coverage such a useless metric: if you have two independent ifs next to each other and one test goes in one if and another test in the other you have 100% coverage. Congratulations. But you've never tested what happens when you go in both

[deleted]

Re: What I wish I knew when I became CTO

#165

Post by tehlike »

baconomatic wrote: post #124
senoroink wrote: post #123

Earlier quoted context omitted.

Why? It's not hard to do if you start a fresh project.

Just because you have coverage doesn't necessarily mean that you have written good tests. That being said, we do something similar where we require 80% coverage.

The difference between 80% coverage and 100% coverage is overrated. 80% is more than sufficient, i'd even go ahead and say 70% is better.

100% goes into "change detecting test" territory. There's also the time aspect: going from 0-70 is not hard, 70-100 is extremely time consuming, and often not worth the effort.

Monitoring is a way more efficient tool at catching issues.

Re: What I wish I knew when I became CTO

#167

Post by rowyourboat »

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.

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

In my experience, if you are unsure of how you are going to solve a problem, writing test only makes you slower. When you are coding exploratively, you will likely have to delete and completely rework what you did several times before you find what works. If you write tests for all but the highest level, those will just be scrapped along with the rest of the code.

Re: What I wish I knew when I became CTO

#168

Post by rowyourboat »

nine_k wrote: post #121
bowlich wrote: post #77

Earlier quoted context omitted.

I remember my agency days. Now days I work on a single long-running legacy project where tests make sense. Back then, I read a lot about how testing was the "right thing to do." But I also realized that most of the time (a) the client wasn't going to be willing to pay for the tests and (b) odds are that once we launch the product, that will be last time I ever look at it. Maintenance will occur in five years when sal…

It's a very interesting setup: all prod code is "throwaway". I wonder if each such project is built completely from scratch. If not, the reusable parts can be improved over time, and covered by tests.

The typical stuff an agency can reuse is all covered by frameworks and libraries anyway.

You take an existing CMS or shop software and customize it, or take a web framework and build a very customer-specific service on top of it. Most everything you can share between CMS projects is already part of that CMS.

Re: What I wish I knew when I became CTO

#169

Post by icebraining »

millstone wrote: post #159
fsloth wrote: post #153

Earlier quoted context omitted.

I'd say that is an architecture problem up to a point. A test does not need any framework. Simply a defined output for a defined input, and then check whether the output matches expectations.

In this sort of scenario, the bugs lie in the expectations themselves. Tests that don’t account for that are dead weight.

Can you expand on that? Because I don't see how a test can account for the faulty expectations of the person writing it.

Re: What I wish I knew when I became CTO

#170

Post by Oras »

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…

In startups, specialised engineer would not necessarily add a good value due to how fast things are changing and mostly lack of proper spec. Specialised engineer can find a good solution with a proper structure which startups lack.
Post reply on HN