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

251–258 of 258 posts

Re: What I wish I knew when I became CTO

#251

Post by mbesto »

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.

I think there is some semantics here. A CTO at all levels needs to have an understand of their (1) current stack of technologies and understand how it improves the business (2) a future stack of technologies and how it may improve the business in the future.

Specifically this could mean as minuscule as "We're using RoR for our website" to more broad like "We need to have sensors in every food package we ship to manage our supply chain and we use IBM IoT platform to do this". The point is have a defined vision with subsequent technology choice behind it. Whether or not you have a Lt that helps drive those decisions is moot.

Re: What I wish I knew when I became CTO

#253

Post by apocalyptic0n3 »

mikekchar wrote: post #238
apocalyptic0n3 wrote: post #207

Earlier quoted context omitted.

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

We have plenty of those as well, but the overwhelming majority of them are about 2-3 weeks of work once we get started

Re: What I wish I knew when I became CTO

#254

Post by elliotec »

rhaps0dy wrote: post #248
chopin wrote: post #212

Earlier quoted context omitted.

Tests help very much against regression. And if you have mixed people touching the code. Anecdotal: I once helped out a team who was writing a Maven plugin for doing static tests on some js code during build. There was already a test suite with a bunch of test code. As my stuff was fairly complicated and I have a habit of writing unit tests for such I added a bunch. Fast forward a year and a half later: I was greeted…

>Firing up git blame was next... I like your story, but I find amusing that `git blame` has such an appropriate name.

Linus Torvalds wrote it so it's pretty typical of his style.

Re: What I wish I knew when I became CTO

#255

Post by scooble »

vlovich123 wrote: post #229
forgotpw1123 wrote: post #146

Earlier quoted context omitted.

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…

Unit tests aren't supposed to find all bugs. Moreover, if you're not enforcing that the tests have to pass before merged/pushed into a shared branch they are beyond useless because they age & more importantly the pain of broken tests is multiplied as it escapes the developer making the change to the entire team being blocked. To understand how unit tests are useful, you look at how code is developed. Typically there'…

"This is frequently a simpler environment to do so as you can control the inputs in a more fine-grained manner than you might otherwise"

One of the things that really sold me on unit tests for Django development was realising that it was quicker to write a test than to open a shell, import what I was working on and run the code manually.

Re: What I wish I knew when I became CTO

#256

Post by chopin »

rhaps0dy wrote: post #248
chopin wrote: post #212

Earlier quoted context omitted.

Tests help very much against regression. And if you have mixed people touching the code. Anecdotal: I once helped out a team who was writing a Maven plugin for doing static tests on some js code during build. There was already a test suite with a bunch of test code. As my stuff was fairly complicated and I have a habit of writing unit tests for such I added a bunch. Fast forward a year and a half later: I was greeted…

>Firing up git blame was next... I like your story, but I find amusing that `git blame` has such an appropriate name.

My sibling beat me to it, but I always thought that it was called this because of the need for it for exact the reason I described in my post...

Re: What I wish I knew when I became CTO

#257

Post by spdionis »

deckard1 wrote: post #201
arekkas wrote: post #176

Earlier quoted context omitted.

Let's break this down. > I'm convinced that unit tests don't usually find bugs. They don't, they test whether or not the API contract the developer had in mind is still valid or not. > 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. You don't write test to find bugs (in 98% of cases), but you can write tests for bu…

> Developers must have the capability of quickly testing the system without manual work Running unit tests is hardly quick. Especially if you have to compile them. End-to-end are even worse, in this regard. > They don't, they test whether or not the API contract the developer had in mind is still valid or not. If you're always breaking the API, then that's a sign that the API is too complex and poorly designed. The A…

> implementing a unit test will take an entire day with marginal benefit

The benefit should be realizing that if you need an entire day to implement an unit test you're doing something very very wrong.

Re: What I wish I knew when I became CTO

#258

Post by murftown »

rhaps0dy wrote: post #248
chopin wrote: post #212

Earlier quoted context omitted.

Tests help very much against regression. And if you have mixed people touching the code. Anecdotal: I once helped out a team who was writing a Maven plugin for doing static tests on some js code during build. There was already a test suite with a bunch of test code. As my stuff was fairly complicated and I have a habit of writing unit tests for such I added a bunch. Fast forward a year and a half later: I was greeted…

>Firing up git blame was next... I like your story, but I find amusing that `git blame` has such an appropriate name.

"git annotate" does the same thing, but "git blame" can be more fun / dramatic if you're looking into the cause of a problem.

Interestingly, "svn annotate" had 2 aliases: "svn blame" and "svn praise". But git didn't add a "praise" alias, just "blame". I actually almost submitted a PR to add "git praise" one time.

Post reply on HN