I just turned 50 in October, and have been coding my entire career plus. I still love and enjoy coding, and feel like I have more to contribute by far than I did early in my career. I have founded a smallish dev studio in Cincinnati (Launch Scout) that I started with a few other developers in 2009. I've tried a few different roles as the company has evolved, but eventually realized that I love coding and helping other people get better at coding. Management, organization leadership, etc, are all important but I've had to (with some misgivings at times) allow other people to fill those roles so I can do what I'm really best at. It can be very frustrating to see our industry fail to learn sometimes. I think the lack of TDD being as widely adopted, and the wide embrace of technologies like React that make development incredibly more complex than is necessary are my two big sources of frustration right now. But I still love learning, and love seeing new ways to make things much better. I still love building things. I'm inspired when I remember how my good friend Jim Weirich was actively coding and teaching right up until he passed away. Right now, my hope is to follow in his footsteps. I think there are a few of us who are like minded. A few years back I tried to organize a group I called Geek Geezer Guild. It might be time to resurrect that.
I'm turning 50 this month and a professional developer since I was about 21-22.
> I think the lack of TDD being as widely adopted
Hilariously, I just got -4'd (and a whole thread) for asking why someone didn't just write tests, instead of building some half baked tool to debug their websocket app. The responses were all sorts of absurd excuses. I'll happily take the negative karma, cause I know it brings some awareness.
(Now I'm getting downvoted again. Oh hn, you crack me up.)
I dislike meta posts generally, but I'll give it a go so maybe you learn.
> Now I'm getting downvoted again. Oh hn, you crack me up.
Because you were whining about down votes.
Generally, when I see someone whining about voting, I'll vote down without a second thought, regardless of the content of the post. Why?
From the guidelines: "Please don't comment about the voting on comments. It never does any good, and it makes boring reading."
I know a good number of other people react this way as well.
Instead of whining about getting voted up or down, instead, use this as an opportunity to improve your messaging.
> I'll happily take the negative karma, cause I know it brings some awareness.
Up-voted comments bring more awareness. If you truly cared about bringing awareness to something, you'd want to communicate effectively, and effective communication is critical in our field.
Anyways, I generally hate meta comments like this one, but hopefully you have a better understanding of why people are most likely down voting this comment.
That said, my intention wasn't to whine. I truly don't care about the act of getting downvoted.
What I was trying to point out is that I was getting downvoted in my original post, because "kids these days" are against the general concept of TDD. That's in response to this OP's comment that I quoted.
Why were they against TDD? One person said it was because their CTO made them do 100% test coverage and that caused the startup to fail. Is that the failure of TDD or the failure of the CTO? ;-)
Now you're getting downvoted? LOL! For the record, I upvoted you.
I'm all about testing especially at the unit level but I've never personally seen TDD implemented successfully. I won't lie, I'll write my code, write my tests, refactor based on new learnings, check coverage stats, and PR for feedback. I'm also 40+ too.
I have seen TDD done successfully, at a few companies. I think it's one of those things where you really have to learn it by doing it with people who already know it. I can well believe that there are people who read a blog post, started doing it, and got terrible results.
It also requires quite a bit of discipline, or commitment, or conscientiousness. It's worth it, but you have to be on the ball. It helps a lot if everyone on the team is experienced in TDD and positive about it, because you can all support each other.
It requires constant occasional investment, in building test infrastructure, updating older tests, etc. Often not a lot, and you can do it as you go. But sometimes, particularly for integration tests, you have to sit down and bash out some sort of framework to make testing tractable at all.
And it's possible it doesn't work everywhere. In my current job, i write a lot of applied maths code, and i haven't worked out how to test-drive that, because i generally don't know what the result should be before i start (i wouldn't need to write it if i did!). Sometimes i can make relative assertions ("the antimatter consumption at warp six should be eight times the antimatter consumption at warp three"), and sometimes i can calculate rough bounds by hand ("the antimatter consumption at warp one should be within 20% of the inverse relativistic mass"). But mostly, i implement something, then run it on a lot of data, plot the output, and decide if it looks roughly right.
You're right, I didn't 'get it' until I worked at a place that was all TDD and I was surrounded by people who took it seriously. It wasn't about 100% coverage or any forced mechanics. It was simply a group of people who were all on the exact same page working on the same exact methodology. Almost a 'cult' of programmers.
> i haven't worked out how to test-drive that
That's exactly it. I don't always see tests as being necessary for greenfield code. You don't have to test drive it. But, you should write tests. Once you figure it out and have things in a place where you're comfortable, write a test so that when you go back and make a change later... you know that the code will break tests and you can be confident of 'change over time'.
I was in the middle of writing a reply to the comment you replied to, when i had to stop because my app was crashing in staging, because i had written a unit test for integration code.
I built an app that ran on 30k+ servers across multiple data centers and it had an auto update mechanism because the app needed to be routinely updated with new features.
I had an integration test that ensured that the app would start up correctly and that the self-update mechanism worked. Without those tests, any failure to start would cause me to have to "talk" to 30k+ servers to get it to install a new version of the app. (ssh into each server and re-install the app).
Automating that communication across that many servers (many of which could be rebooting at any time) and ensuring that they all had a running version of the app, was difficult to say the least. How do you even track that the app is running? (You end up having to have a ping mechanism too!)
Of course, I didn't start off with those tests and had to do things the hard way more than a few times. The thing is that once I added the tests, I never once had to do things the hard way again.
So, you can certainly do things the hard way, or you can just write tests and be done with it and work on features instead.
You're old enough then to have used message boards before they turned into a popularity contest with voting. It's easy enough to just ignore those features entirely.
Actually, it was in person the one time we had it but we brought in the speaker from out of town. It was Glenn Vanderburg, who is is a smart and fabulous human being around my age (possibly a bit older) and he gave a great talk. I'll keep noodling on what the best reincarnation would look like. I think we possibly recorded it, I'll have to try to find it...
