breaker-and-a-half

@breakerandahalf@fedi.tali.network
9 Followers
25 Following
186 Posts

Writing bios is hard, largely because succinctly describing oneself to an extent that allows others to see oneself to the same extent as one sees themselves is impossible. What follows should be a serviceable approximation.

In brief, I am a computer science student, amateur radio operator, electronics hobbyist, technical theatre person, railfan, electric power transmission appreciator, cyclist, and nerd.

Header image by Harvey S. Rice or Craig Holstine and avatar image by Robert C. Stewart. Both are from the Historical American Engineering Record project, which produces documentation singularly amazing in breadth and depth.

Posts and boosts may sometimes include strong language. I don't post or boost NSFW content (in the traditional sense—occupational safety hazards are sometimes discussed, though).

I welcome disagreement, criticism, feedback, and debate, but do not tolerate hatred or bigotry. If you engage me in good faith, I will gladly reciprocate (provided I have the time to engage at all).

Pronounshe/him
TimezoneAmerica/Los_Angeles
LocationPortland, OR, USA
breaker-and-a-half5d ago
Show threadbreaker-and-a-half5d ago
Corollary: calling your own argument "speculative" is a succinct way to be honest about the foundation of your arguments/predictions, and steers others towards examining whether your assumptions and speculation are correct or not. It can thus be very useful in the right sort of discussion.
Show threadbreaker-and-a-half5d ago
Corollary: calling your own argument "speculative" is a succinct way to be honest about the foundation of your arguments/predictions, and steers others towards examining whether your assumptions and speculation are correct or not. It can thus be very useful in the right sort of discussion.
breaker-and-a-halfJun 30
BET IT ALL ON DOSKELJun 28
the fediverse is the only platform where i could find other people who have recreationally read the DoT Manual on Uniform Traffic Control Devices
breaker-and-a-halfJun 21

Argument tip: if an argument relies on a prediction about the future or present that you doubt, the best way to counter that argument diplomatically could be to call it "speculative". This is a good way of pointing out that that argument relies on information that is unlikely to be true without directly accusing the maker of the argument with lying or arguing untruths. It also carries with it the implication that it's prudent not to rely on the truth of speculation that could be wrong. (You may want to state the latter implication aloud for the avoidance of doubt or to strengthen your argument.)

If someone is suggesting a course of action that relies on an unduly speculative prediction to work, then you may want to suggest an alternative that assumes that the speculative prediction will not come to pass and acts accordingly, but provides for the suggested course of action to be followed if the prediction is correct.

Show threadbreaker-and-a-halfJun 20
@raiderrobert AI coding tools make the disconnect between writing and critically reading code so much worse. Language models are fundamentally unable to differentiate between the stated purpose of code and the function it actually performs, and the ability of people to generate large codebases that they don't understand just makes the task of picking up the pieces after an inevitable failure worse. And using AI generation of code to learn how to code means that students don't learn how to debug the code they've "written", setting them up for even more failure. Lack of engagement with the internal or detailed aspects of the programming language or libraries being used makes it hard to keep code stable and up-to-date as interfaces change. Lack of familiarity with how the software that one has produced works results in an inability to analyze its security, contributing to the serious security problems that we have been seeing with AI-generated code.
Show threadbreaker-and-a-halfJun 20

@raiderrobert My advice to those getting into computer science either on one's own or through formal education, is not to skimp on debugging experience. If you've got access to formal tutoring, use it as much as is necessary (or as much is as feasible) until you feel comfortable reading and analyzing code as much as you do writing it. One one-hour tutoring session will not teach you how to debug, but establishing a program of consistent engagement with computer programming and debugging as an activity will give you skills that are unfortunately underrepresented in the classroom.

I can't tell anyone how to develop a program of debugging education, but I have some tips. Spend time doing reverse-engineering—which is just debugging put towards different ends—or making subtle changes or tweaks to existing codebases. Look at the internals of library functions. Run experiments on your code to see how it breaks. Whenever you see software (or any sort of engineered system) put to use in the real world, spend a moment thinking about how it works and how it can break (or is broken).

breaker-and-a-halfJun 20
Robert RoskamJun 20

Kernighan's Law summarized: Debugging is twice as hard as writing code. If you write code as cleverly as possible, you are not smart enough to debug it.

The most clever solution is rarely the best for a team environment.

Code is read far more than written. Choose clarity over cleverness. Your future self will thank you.

Show threadbreaker-and-a-halfJun 20

@raiderrobert This is absolutely correct, and so many people have to learn this the hard way in computer science education and in software engineering. I feel as though debugging is a "soft skill" that's difficult to teach and underrepresented in computer science curricula, particularly in the theory-heavy computer science education that I received. Students who know how to write code but lack the skills and thought process to debug the code they've written are set up to fail. So many students hit a wall when their ability to write code exceeds their ability to think about how their code is going to work or how to fix it if it's broken. I speculate that one significant cause of imposter syndrome within computer science is that some students find it hard to develop a skill that their classroom education fails to teach them and yet is critically important to their work, while other students have this skill but can't explain how they got it.

My advice to students and my thoughts on the biggest practical disadvantage of AI coding tools are below.

breaker-and-a-halfJun 11
The only SI ↔ US Customary unit conversion that I know is 1 in == 25.4 mm, and I know that because of constantly seeing parts whose lead pitch is quoted as "2.54 mm (0.1in)" or the like.
breaker-and-a-halfJun 11
JPJun 9
digging around in my 2K Marin-era (2008-ish) archives and came across this outstanding error message, props to whatever IT(?) person decided to phrase a simple seat license conflict as "Human Combat Required":