Mark Tomczak @mtomczak@qoto.org
- My Page
- https://fixermark.com
Career software engineer living something approximating the dream he had as a kid.
Joined Apr 2022
Followup on previous thoughts.
When I speak of "Test-driven development," I'm usually thinking of unit tests and integration tests. I think building those out before you have a concrete implementation tends to be putting the cart before the horse. They're most useful as regression tests to make sure you haven't broken something important when you make changes in the future.
Test-driven development can be quite valuable for end-to-end tests if you can get the client to agree on what the software is supposed to do in the form of a walkthrough of the behavior. I still tend to put this alongside or slightly after the initial design (most clients I work with aren't abstract system thinkers, so it's real hard to get them to understand a design they can't see and touch), but getting the client to agree that their initial ask matches to a test script of the form "User goes to A, clicks B, enters C, should see D happen" is a form of test-driven development when you implement a program to satisfy that script.
... but I still tend to keep that script hand-written before wasting the cycles on automating it in code.
@freeschool Sorry, that should have been "test-driven development."
What I mean is specifically unit test-driven development, like in https://methodpoet.com/unit-testing-vs-tdd/. Consistently, I find that when a new feature is requested, the details of how the feature is to be implemented aren't well-enough understood to begin writing unit tests against them. So most attempts to do TDD that I've seen result in ripping up 100% of the unit tests and starting over, eventually.
The exception is minor modifications to existing features, where changing the test first and then the implementation works fine. But if new classes, functions, or entire APIs need to be developed, I find that writing the unit tests first gets in the way of the exploration necessary to nail down the desired shape of the finished product.
Broadly speaking, a few principles guide my software engineering these days:
* Automated tests: Great, must-have, let you make guarantees about what your software will do, write them and have them.
* User stories: Great, must-have, make sure you're writing the correct thing, make them and implement to them
* Test-driven design: Terrible, big waste of time, borderline anti-human practice, assumes omniscience. Don't stress about this; just write code.
And now, the conclusion to the story of College Technology University.
http://personal-blog.fixermark.com/posts/2022/the-story-of-ctu-3/
The story of College Technology University part 2, where plans are slightly derailed because people are involved. http://personal-blog.fixermark.com/posts/2022/the-story-of-ctu-2/
It's weird / funny to me how comfortable I've gotten in TypeScript, to the point that I prefer it over Java consistently. Not an outcome I would have predicted, but Microsoft does have a knack for building and maintaining good languages.
It's the hundred little things, like the fact that TypeScript constructors are (a) named "constructor" (one fewer thing to change in a refactor that renames the class) and (b) have a syntactic shortcut for passing in arguments that do nothing but get retained in the object state. Every time I write Java and I have to pass in a Foo named 'f' so I can write 'foo=f' in the constructor body, I die a little inside.
Mark's principle of sufficient comments: Any meta-programming demands comments to demonstrate how to use it in the language you are meta-programming on top of.
In which I convince a bunch of players to accomplish goals for me by roleplaying a college dean.
http://personal-blog.fixermark.com/posts/2022/the-story-of-ctu-1/
A lot of the stuff we see on Mars could easily be transplanted into an Earth desert.
But from time to time, she reminds us she's an alien planet with one third of Earth's standard gravity.
https://www.sciencealert.com/check-out-the-twisting-towers-of-rock-curiosity-found-on-mars/amp
I've been trying to get back to at least as much control theory as I understood in my college days, and this is a pretty neat explainer of the notion of stable vs. unstable control systems (what they intuitively mean, without diving headlong into the math of how we get the systems model to tell us if we're looking at a stable / unstable one).
https://jbconsulting.substack.com/p/you-need-to-know-what-right-half
First explainer I've ever seen of Taylor series that really clicked for me.
https://www.youtube.com/watch?v=3d6DsjIBzJ4
In general, I wish more of calculus had been taught to me not as a fundmental math that is abstractly internally-consistent, but from its historical origins: "Physics and engineering are hard, here's some brilliant hacks people came up with to make the estimates and calculations tractable." Then you can go from those to why they work to get to the theoretical context-free calculus.
Here is the fundamental difference.
In application-level programming, there is such a thing as a function that is guaranteed to succeed and return.
In systems-level programming, no such creature exists.
Ye young people who seek understanding of the computing world: this is not the whole of the law, but it is the law.
The image that appears in my brain whenever someone says anything like "C is a fine language if you just use it right."
Part one of thinking about simulating drivetrains. #frc
https://fixermark.blogspot.com/2022/05/simulating-differential-drivetrain-part.html
@hamptos You are in a maze of twisty social networks, all alike.
Hello world. :)
- My Page
- https://fixermark.com
Career software engineer living something approximating the dream he had as a kid.
Joined Apr 2022
