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

231–240 of 258 posts

Re: What I wish I knew when I became CTO

#231

Post by rmccoy6435 »

mratzloff wrote: post #184
rmccoy6435 wrote: post #135

Earlier quoted context omitted.

I'm in 100% agreement with you up until the point of tying your test coverage and writing of tests to your employment. In my eyes that promotes a culture of writing bogus tests that provide no value other than to make more green check marks. You should be encouraged to write tests by your colleagues and be in a culture that sees the benefits, rather than forcing people to do it. I'm also unsure if sitting one develop…

Bogus tests have to be caught in code review. When I talk about educating the team that's what I mean. I've only ever had to do a test rotation once or twice, and it was like pulling the rip cord on a lawnmower. Requires effort at first and then it becomes self-sustaining over time. It establishes or affirms a culture of testing. The rotation doesn't even need to last long. You should know which portions of the code…

If you are a company trying to integrate the idea of Unit Testing into a company and it is a new concept, I guess this practice could be acceptable. I think context really matters. I've put a lot of thought into this throughout the day, and I'm completely torn. On one hand I see the benefits of trying compensation to it, but I also just see it creating more problems than solutions. Especially if later on it becomes a cultural standard in the office, how on Earth are you going to remove that benefit (because you no longer need to encourage it) without pissing people off?

Also for the latter point I guess that also depends on context. If you work for a consulting company you may not have the full knowledge of what the code base is, or even have direction to be touching some things. If you are developing software for your own company, I do agree you need to figure these things out, and maybe having a developer dedicated to it each sprint isn't a bad idea. I overstepped my bounds on that comment, as I have never worked for a company that makes its own software it sells, I've only ever done consulting and I sometimes forget about alternative perspectives, so sorry about that.

Re: What I wish I knew when I became CTO

#232

Post by Const-me »

kemitche wrote: post #223
saguro wrote: post #187

Earlier quoted context omitted.

There's a much easier way to break it down. Tests are a pattern. And patterns are the bread and butter of the medicore. That's not to say that patterns or tests are bad, but high calibre guys know when to use which tool. As a tool, unit testing is almost useless. Low calibre guys don't have any feel for what they're doing. They just use the tools and patterns they were taught to use. All the time. This goes from engi…

I find unit tests to be _most_ useful in very particular cases: When a given function I'm writing has a set of input/outputs that I'm going for. Various items like parsing a URL into various components, or writing a class that must match a particular interface. I need to make sure the function works anyway, so I can either test it manually, or I can take a few extra moments and commit those test cases to version cont…

The applicability of unit testing to your particular cases varies greatly across languages & runtimes.

For URL parsing, some runtimes/frameworks have that thing already implemented. E.g. in .NET the Uri class allows getting scheme/host/port/path/segments, and there’s a separate ParseQueryString utility method to parse query part of the URI.

To ensure a class conforms to an interface, the majority of strongly-types OO languages have interfaces in their type systems. If you’ll use that but fail to implement an interface or some parts of it, you code just won’t compile.

Re: What I wish I knew when I became CTO

#233

Post by petraeus »

forgotpw1123 wrote: post #146
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…

PR comments I agree with, but after believing in unit tests for years I'm drifting slowly into the "waste of time" camp. I'm convinced that unit tests don't usually find bugs. IMO, most bugs are edge cases that were an oversight in the design. If the dev didn't handle the case in code they're not going to know to test for it. Fuzzing is a much better approach. At my current position I have the opportunity to work wit…

Tests by definition are recursive, you need to know what to test for before you can test it.

Re: What I wish I knew when I became CTO

#234

Post by mratzloff »

rmccoy6435 wrote: post #231
mratzloff wrote: post #184

Earlier quoted context omitted.

Bogus tests have to be caught in code review. When I talk about educating the team that's what I mean. I've only ever had to do a test rotation once or twice, and it was like pulling the rip cord on a lawnmower. Requires effort at first and then it becomes self-sustaining over time. It establishes or affirms a culture of testing. The rotation doesn't even need to last long. You should know which portions of the code…

If you are a company trying to integrate the idea of Unit Testing into a company and it is a new concept, I guess this practice could be acceptable. I think context really matters. I've put a lot of thought into this throughout the day, and I'm completely torn. On one hand I see the benefits of trying compensation to it, but I also just see it creating more problems than solutions. Especially if later on it becomes a…

No worries. Note that I am not saying you get rewarded for doing the bare minimum (writing tests). You get rewarded for going above and beyond. You are not performing the minimum requirements of the job if you do not include tests.

Of course you combine this with managerial support and coaching around task planning and messaging to other groups.

I've been a consultant, too, and I agree that it can sometimes (for some clients) be difficult to make the case for testing in that environment.

Re: What I wish I knew when I became CTO

#235

Post by dpeck »

gaadd33 wrote: post #133
ecshafer wrote: post #117

Earlier quoted context omitted.

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.

What do you call the person running the company of 10 people? I guess "team lead" would be a non inflated title, or just "manager"? It would be pretty strange to have to explain that title to anyone outside of the company though

"founder"?

Re: What I wish I knew when I became CTO

#236

Post by brett40324 »

geofft wrote: post #125
brett40324 wrote: post #100

Earlier quoted context omitted.

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

What properties do you write tests for, though? Presumably you're touching the code because there's something wrong with it. How do you know how much of it is wrong? How do you know that all callers are actually thinking the current behavior is wrong, instead of one caller misbehaving and another caller expecting it (possibly because someone noticed and worked around it, and now that workaround is going to break)? Te…

I agree, and commend how well you've noted the problems when code is written without tests. Such a codebase becomes mentally exhausting and expensive to probe into; much more expensive than the original time saved by ignoring testing practices altogether. Sure, a huge amount of legacy software may not have tests, let alone comments. Then yes, it's like where do you even begin and have any confidence in what youre testing for. But ignoring proper testing practices in new, modern codebases, especially in a business where the single product or service offering is software, is extremely risky and irresponsible. This is a little ranty because why are devs justifying not writings tests in 2018!

Re: What I wish I knew when I became CTO

#237

Post by saguro »

kemitche wrote: post #223
saguro wrote: post #187

Earlier quoted context omitted.

There's a much easier way to break it down. Tests are a pattern. And patterns are the bread and butter of the medicore. That's not to say that patterns or tests are bad, but high calibre guys know when to use which tool. As a tool, unit testing is almost useless. Low calibre guys don't have any feel for what they're doing. They just use the tools and patterns they were taught to use. All the time. This goes from engi…

I find unit tests to be _most_ useful in very particular cases: When a given function I'm writing has a set of input/outputs that I'm going for. Various items like parsing a URL into various components, or writing a class that must match a particular interface. I need to make sure the function works anyway, so I can either test it manually, or I can take a few extra moments and commit those test cases to version cont…

That's a great example of why unit testing is mostly useless.

Having an expected/input output set when writing something like a parser is standard practice. Turning that set into unit tests is worthless for a few reasons.

1: You will design your code to make them all pass. A unit test is useless if it always passes. When your test framework comes back saying x/x (100%) of tests have passed, you are receiving ZERO information as to the validity of your system.

2: You wrote the unit tests with the same assumptions, biases, and limitations as the code they're testing. If you have a fundamental misunderstanding of what the system should do, it will manifest in both the code and the test. This is true of most unit tests - they are tautological.

3: While doing all of the above and achieving almost zero additional utility, you had to fragment your logic in a way that easily yields itself to unit testing. More than likely, that's not the most readable or understandable way said code could have been written. You sacrificed clarity for unit testability. Metrics like test code coverage unintentionally steer developers to writing unreadable tangled code.

The only use case for unit testing here would be if this parser was a component that gets frequently updated by many people or a component that gets implemented anew for different configurations. But at this point i'm just talking about regression testing, and there are many ways to do that other than unit testing.

Re: What I wish I knew when I became CTO

#238

Post by mikekchar »

apocalyptic0n3 wrote: post #207
mikekchar wrote: post #85

Earlier quoted context omitted.

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…

> I find that tests pay off pretty quickly in terms of productivity -- somewhere around a week. I think you overestimate the agency project life cycle. Most of our projects are built and ready for client review in 2-3 weeks total. Once the client makes a few days worth of changes, the project is shipped and we likely do not look at it again for another year or three. That said, there are always long-running projects…

Interesting. I worked very briefly in an agency a long time ago. Our projects were on the 2-3 month time frame. I suppose it depends on what you are doing.

Re: What I wish I knew when I became CTO

#239

Post by gshulegaard »

forgotpw1123 wrote: post #146
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…

PR comments I agree with, but after believing in unit tests for years I'm drifting slowly into the "waste of time" camp. I'm convinced that unit tests don't usually find bugs. IMO, most bugs are edge cases that were an oversight in the design. If the dev didn't handle the case in code they're not going to know to test for it. Fuzzing is a much better approach. At my current position I have the opportunity to work wit…

> If the dev didn't handle the case in code they're not going to know to test for it. Fuzzing is a much better approach.

I routinely call myself a proponent of BDT (Bug Driven Tests) over TDD for much a similar reason. That said, tests are HUGELY beneficial for guarding against regressions and ensuring effective refactors. Anecdotal but on my current project tests helped us:

* Catch (new) bugs/changes in behavior when upgrading libraries.

* Rewrite core components from the ground up with a high degree of confidence in backwards compatability.

* Refactor our Object model completely for better async programming patterns.

I don't think tests are particularly good at guarding against future bugs in new features; as your comment about fuzzing hits squarely on.

But I DO think tests are good at catching regressions and improving confidence in the effectiveness of fundamental changes in design or underlying utilities version to version.

Re: What I wish I knew when I became CTO

#240

Post by derefr »

darkerside wrote: post #192
derefr wrote: post #93

Earlier quoted context omitted.

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

False dichotomy. Understandings aren't completely wordless or wordable. They fall along a scale. > Anything could have helped. If something helped a person, and they want to pass it along, even if it's difficult to communicate in a tangible fashion, I'm not going to stand in their way.

Sure, but If I want to learn a difficult-to-communicate lesson, I would hope that the people who have a wordless understanding would keep their communicating to themselves—unless-and-until they come up with some coherent words to match their thoughts, that they can be sure can be used to reconstruct those thoughts without their brain there to help.

People don't yet know what they don't know, until they know it—so it can't be the learner's task to preemptively avoid vacuous lessons. That responsibility has to fall to the teacher.

Post reply on HN