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

41–50 of 258 posts

Re: What I wish I knew when I became CTO

#41

Post by muttech »

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…

In my previous agency life, this was something that I experienced as well. A short lived product that was due in less time than any sane dev would estimate. We all knew that we "should" write tests, but there just wasn't time. And in 6 weeks the project would be relegated to living in source control because the campaign was over.

It made hiring devs fun. Trying to explain to people why it was that way, and their insistence that software development doesn't work that way.

Re: What I wish I knew when I became CTO

#42

Post by legitster »

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.

You have to know enough about the thing to know if the person you are hiring is smarter than you at it.

I see this all the time in hiring and acquiring vendors. Management just wants to fill missing talent, but then can't tell they are getting mediocre work.

Re: What I wish I knew when I became CTO

#43

Post by mooreds »

ripberge wrote: post #2

Enjoyed reading this article, all valid points. However, the one thing that stood out to me in this area was how light I was in effective principles of management and leadership. As a CTO of an organization of more than a handful of people you eventually "get things done" largely via other people rather than being hands on yourself. Had to read a lot of Harvard Business Review to gain the skills and confidence for th…

I loved "High Output Management" for a concrete handbook on a lot of these topics: https://www.goodreads.com/book/show/324750.High_Output_Manag...

Re: What I wish I knew when I became CTO

#44

Post by Swizec »

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.

Re: What I wish I knew when I became CTO

#45

Post by joallard »

mberning wrote: post #35

I have quit jobs because we kept bad hires too long and then didn’t fight to keep good hires from walking away. I think grooming and retaining talent is just as important as providing technical leadership. You need to be strong in both areas.

I've seen exactly this in a local well-regarded startup. Incompetent hires with problematic behaviors thriving and being protected, and competent hires being unprotected, not cared about, and almost pushed out.

They would hire almost anyone, and then not take active action in maintaining a healthy staff. Needless to say, it's not going very well over there, regardless of the CTO being quite technically proficient.

Re: What I wish I knew when I became CTO

#46

Post by miketery »

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…

Can you recommend good resources (article/pdf, lynda, etc.) on writing tests? Less about the how (though important too) - but more about when, why, and for what parts/functionality. I find when I do write tests some are so trivial and then I stop doing them altogether.

Re: What I wish I knew when I became CTO

#47

Post by drspacemonkey »

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…

It's much easier to convince people that tests are necessary if you're starting a new project. Problems arise when you're working on a legacy codebase that never had tests to begin with. Often, the code isn't testable at all.

IME, there are far too many "senior" devs (who absolutely should know better) who never worked on any testing-heavy teams that just don't see the point. After all, there's QA, and it's not like THIS code should break THAT code in a seemingly-unrelated part of the codebase...

Re: What I wish I knew when I became CTO

#48

Post by crdoconnor »

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…

Most test writing feels unnatural (especially lower level unit tests). I think this is a tooling issue and an inherent problem with unit tests.

Re: What I wish I knew when I became CTO

#49

Post by michaelchisari »

redler wrote: post #9
ripberge wrote: post #2

Enjoyed reading this article, all valid points. However, the one thing that stood out to me in this area was how light I was in effective principles of management and leadership. As a CTO of an organization of more than a handful of people you eventually "get things done" largely via other people rather than being hands on yourself. Had to read a lot of Harvard Business Review to gain the skills and confidence for th…

It’s funny how, as you progress through a career and gain responsibility, those HBR articles go from seeming like a bunch of Markov chain corporate-speak to being on-target for that exact problem you had last month with the leadership team.

Same goes for philosophy.

However, a good writer should be able to convey even the most advanced topics in accessible ways. Often when I see someone relying on jargon and insider language too much, they strike me as a poor writer, regardless of their grasp of the source material.

Re: What I wish I knew when I became CTO

#50

Post by ryanianian »

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.

Do it for yourself - tell the CTO you're doing TDD to make your own process sane. It would be weird for others to object to you adding tests to your own code. Then others will see your awesome code with great coverage and no bugs in PRs and it may even catch on. Convince one or two colleagues to do it with you.
Post reply on HN