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

211–220 of 258 posts

Re: What I wish I knew when I became CTO

#211

Post by deckard1 »

latch wrote: post #152
sagichmal wrote: post #145

Earlier quoted context omitted.

> I'd say at a minimum, having everyone spend 4 hours a week pair programming should be a goal to try. Pair programming is like nails on a chalkboard to me and at least a plurality of developers generally, based on what I’ve experienced personally and read online. An expectation that I’d do 4 hours a week of it would have me hunting for a new job immediately. It’s different in kind to other practices like mandatory c…

Ok, so that assertion was pretty controversial, but, honest question, what mechanism do you use for mentoring/learning/growth? Code review is the only other activity that I've seen that can have the same type of impact, but I see them as complementary. I'm old, I learned about sql injection and hash salts and coupling and testing by being awful at it for decades. How do I transfer that knowledge so that a 26 year old…

> I'm old, I learned about sql injection and hash salts and coupling and testing by being awful at it for decades.

You pick up a goddamn book, man!

> How do I transfer that knowledge so that a 26 year old can be where I was at 32

You tell them to pick up a goddamn book, man!

Sorry for being curt. But it's the professional responsibility of developers to educate themselves. Some people think they can cram on binary trees in CS, use that limited knowledge to BS the interview, and then coast into working on the transaction system at a bank or whatever.

If a company wants to pay you to mentor a junior, that's one thing. And should be explicitly stated as such. I'm willing to help just about anyone that asks. But if I find myself showing a developer how the compiler works (or a compiler works), or the syntax of our programming language, or basic things that Google knows, I'm going to walk away from that flaming wreck of a company. I've worked with developers that hunt-and-peck typed before. You ever have to explain syntax to a guy that can barely work a keyboard? Let's just say, my threshold for putting up with BS is dramatically lower now.

Re: What I wish I knew when I became CTO

#212

Post by chopin »

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 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 with a mail that there was a bug in it. I had to fight the better part of a day to nail it down: First not being familiar any longer with the code and secondly because a bunch of stuff has been added meanwhile. I fixed and thought it was a good idea to add a test as it was a nasty corner case. I headed for the natural place where the test would go and found -- exactly the test I was going to write, nicely commented out. A quick check with Git revealed that I added this test initially, which then was commented out when the new feature causing the bug was added. Firing up git blame was next... This is why I am fond of having tests: you are stomped onto it if you break something at least if your test suite is worth its salt.

Re: What I wish I knew when I became CTO

#213

Post by blackflame7000 »

afarrell wrote: post #185
blackflame7000 wrote: post #141

Earlier quoted context omitted.

Testing is absolutely critical don't get me wrong, but you can't test what you can't predict, so there needs to be a distinction between tests that really stress the system in unknown ways vs verifying your ADD function did indeed add N consecutive numbers correctly.

> verifying your ADD function did indeed add N consecutive numbers correctly This kinda depends on if it is a public or private (or `__private(self):`) method. If its private, no need to test it. But suppose that rather than using something in an existing library, you are bothering to write your own ADD function and expose it to the rest of your codebase. Wouldn't that indicate that your function was special enough t…

I mean yea it should be tested, but making a code change that propagates through the rest of the repository is really poor abstraction design. At that point, you might as well have one class called tester that holds pointers to everything and is about 100K lines long.

Re: What I wish I knew when I became CTO

#214

Post by tonyarkles »

coupdejarnac wrote: post #118
leoc wrote: post #105

Earlier quoted context omitted.

It's aside from your point, but would that Toyota's embedded software were as good as its mechanical engineering...

Anecdote time. My former company outsourced embedded development to the company that does firmware for Toyota. It was a complete disaster, and a year of work had to be scrapped. Code was rife with cut and paste, badly reimplemented mutexes when they could have used the ones supplied with the RTOS, and other nonsense. I suspect the Japanese company put all their deadweight engineers on the project.

From my understanding of the "unintended acceleration" lawsuit, you could very well have had the exact same engineers who implemented the Toyota firmware :).

Re: What I wish I knew when I became CTO

#215

Post by corpMaverick »

darkerside wrote: post #80
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…

> a company that sees quality and efficiency as opposing forces, or one that sees them as inseparable. I just wanted to say that this was beautifully stated. I've been looking for better words to explain this concept to the people around me.

I imagine it is thinking along this lines...

https://totalqualitymanagement.wordpress.com/2008/09/12/cost...

Definition of cost of Quality It's a term that's widely used – and widely misunderstood. The “cost of quality” isn't the price of creating a quality product or service. It's the cost of NOT creating a quality product or service. Every time work is redone, the cost of quality increases. Obvious examples include: The ...

Re: What I wish I knew when I became CTO

#216

Post by deckard1 »

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

A few years back a person I worked with was tasked with implementing code coverage. Part of that task was they also had to get our code base up to 80% coverage or so.

They wrote stupid test after stupid test after stupid test. Hundreds of them. Oh Em Gee. It was like that story of Mr T. Where the army sergeant punished him by telling him to go chop trees down, only to come back and find Mr T had cut down the whole forest.

Re: What I wish I knew when I became CTO

#217

Post by anoother »

apocalyptic0n3 wrote: post #203
muttech wrote: post #41

Earlier quoted context omitted.

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

> A short lived product that was due in less time than any sane dev would estimate. > And in 6 weeks the project would be relegated to living in source control because the campaign was over. That is exactly it for 90% of agency projects. Underquoted to get the deal, a rapid development cycle that leaves the devs feeling dead, and then once that first release is out, you have maybe 1 or 2 small updates and the project…

What does 'agency' refer to in this subthread?

Agency for what?

Re: What I wish I knew when I became CTO

#218

Post by dolinsky »

cbodolus wrote: post #104
ryanianian wrote: post #50

Earlier quoted context omitted.

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.

Respectfully I disagree. I’ve found that ‘talking about doing it’ will cause problems if you aren’t able to do it and hold schedule with everything else. From personal experience, for parent post, I’ve found it’s been best to implement what you can for unit tests and grow it yourself slowly or at whatever pace you are comfortable with, but set the bar high for yourself, beat it, and then maybe try to get others on bo…

forgiveness > permission

Re: What I wish I knew when I became CTO

#219

Post by pavel_lishin »

bkeroack wrote: post #136
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.

Tests absolutely cost time, inversely proportionate to the raw ability of the programmer. A 95th percentile engineer can write cowboy code with zero tests that largely works. Enforcing tests could cause up to a 50% slowdown. It’s probably worth it in the long run, but for a time and cash strapped startup its a legitimate cost/benefit analysis.

God save me from code that "largely works".

Re: What I wish I knew when I became CTO

#220

Post by [deleted] »

fsloth wrote: post #199
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…

I think it probably depends on the complexity of the code as well. I can't count the number of times my unit tests on projects I alone maintain have saved my ass from releasing some unwanted bug into production due to a change I did. Especially, if the codebase evolves due to new end-user requirements being discovered along the lifetime of the project unit test on various corner cases can be a lifesaver. I'm not a ba…

[deleted]
Post reply on HN