Programming

So this is going to be odd coming from a guy working at a place with a Leadership Principle saying “Speed matters in business” If I’m doing my job right, I consider myself to be a “slow” developer. I’ve watched the recent explosion across my social feeds about AI SUPERCHARGED DEVELOPMENT ENVIRONMENTS! like Copilot, Cursor, Windsurf, Claude, and Warp Terminal. They all seem neat, and this seems like a Nova (if not a Supernova) of dev tooling we haven’t seen since Netbeans/Eclipse/IntelliJ battled it out 15 years ago to see who could make IT departments upgrade from 512 MB developer machiens fastest. ...

Meta This chapter alone is SDE Mentoring 101. Many of my mentees through the years have struggled in these areas, and improvement is often following these principles, whether by design or by accident. This is a “soft” skills chapter, yes. Later ones get much more technical. However, most tech ICs (and managers) don’t struggle with technology; we struggle learning these lessons ad-hoc, through experience. – Harold, 08 January 2020 Foreward & Preface They don’t talk down to you. They don’t assume you are an expert. … They take you as you are–programmers who just want to be better. ...

Hackathon (n) 1. a design sprint-like event in which computer programmers and others involved in software development, including graphic designers, interface designers, project managers, and others, often including domain experts, collaborate intensively on software projects. The goal of a hackathon is to create usable software or hardware with the goal of creating a functioning product by the end of the event. I posit Hackathons are Crap. They are useless distractions from Actual Work® that have none of the intended outcomes for anyone involved. ...

I’ll never forget M. M was my mentor, and we didn’t always get along. I chose him as a mentor because we didn’t get along. I needed someone who had different perspectives than I did. Anyway, one of our early meetings, I talked about people at work I admired. I expressed that I admired a guy we’ll call Brad. Brad was a guy I’d worked with many times. He was part of senior leadership, and he still found time to write code, on the evenings and weekends if necessary. At the time, his architecture team was embroiled in doing the scut work of rolling-out “Agile Development” to a hardware-development organization. (Another really long post for another day….) ...

Too long for a tweet. Too short for a blog post. These are some tech-related skills I’m glad I have. They come in awfully handy: Touch typing. You’d be surprised at the number of people who work with computers for a living who can’t actually touch type. Markdown. Markdown is incredibly handy for tossing-off documentation and forum responses. I’ve actually considered hosing this blog entirely and converting to posts hosted on Github, formatted in Markdown. ...

So, during my job-hunt, I spent at least an hour a day on HackerRank. I highly recommend the site for anyone learning to code, sharpening their skills, or learning a new language. Anyway, so at my new job we use Java8 extensively. I’d had cursory exposure to Java at my last gig, but mostly in the “Why won’t this frigging library run with my Java 1.7 JVM?!” variety. So, it was time to learn something new. Narturally, I thought of HackerRank and it’s Java tutorials. ...

Reference: Why Go’s design is a disservice to intelligent programmers I honestly can’t decide if this article is sarcastic praise for #golang hitting every one of its design goals, because once you look past the ad-hominem crap, it’s there: “Similar to Go, the book is easy to read with good examples and clocking in at about 150 pages you can finish it in one sitting.” Read: Go’s easy to learn. The documentation is excellent. “I’ve always thought that the developers at Google are hand picked from the brightest and best on Earth. Surely they can handle something a little more complicated?” He misses the point entirely. Those same devs choose to go away from the frills to get leaner and faster. Code is a means to an end at Google, and they realize that it’s going to be read by other developers many times more than it’s written. Simplicity and clarity surmount all else; Google’s stultifying C++ style guide makes this apparent. “There are no shortcuts in Go, it’s verbose code or nothing.” Shortcuts get abused. See: C preprocessor macros. I read this as “‘I have to check return values and handle errors’ == verbose code.” This is not a valid Software Engineering view. IMO, it should be obvious whether code handles errors properly. “The language could be described as C with training wheels.” Thanks! I rather like C. I just wish it had a decent Standard Library, no header files, less “undefined” behavior, inbuilt concurrency, package management, and garbage collection. ...

“Well, sir, you certainly didn’t have afternoons like *this*, when you were doing the Architect Gig.” Gotta love that inner critic. There’s always something. My response: Indeed, but I didn’t *ever* have weeks like last week where we found and solved problems in realtime with a team of engineers, either. It was lonely, and devoid of the kind of dopamine-enhanced highs I got. Last week was hard. Every day except for Wednesday, I was here ’til late. On two nights, mine was the last car out of the parking log. Snowpocalypse 2015 put us behind, and a Linux/PAM story that won’t die put us even farther behind. ...

I still remember an interview I had around February 2001, in which +Ron Garnett talked about how his team wrote code: We write stuff in Assembler, because we’re too lazy to write stuff in C. Wait…what? I thought the whole purpose of C was to have portable Assembly, so you could control the bare metal correctly. I did get an inkling if you were that good, assembly could be seductive in your ability to do whatever you want. ...

Saturday, I took my daughters to the kids day/open house down at our local PBS station. Getting past the claustrophobia of jamming hundreds of kids, strollers, and overwrought parents into the narrow hallways and anechoic studios, it was great kidly fun–lots of booths, sing-alongs, and face painting. On our way out, we noticed a smart-looking medium duty truck painted like a firetruck, pulling a trailer packed to the gills with equipment. Inside were two “simulator” booths where two robust gentlemen were showing how they train police officers and firemen to drive their vehicles in all sorts of conditions and situations. ...

Ramping on a new project is fun! Actually, it resembles lighting yourself on fire, running and jumping onto a moving train with jugs of water on it, only to discover the first car has flammable liquids, then the next car, then the next. Restated: It’s never boring. So, I’m collaborating with a team writing in Rails 4, and that team’s adopted the 12 Factor App religion. Great! I’ve dabbled in heroku before, and it’s neat to see apps written that way from the first git init. ...

I’m part of an initiative developing curriculum and training resources for developers. Here’s what I have so far on fundamentals and skills for a developer. Fundamentals Design and Structure • Design / Domain Modeling • Object Orientation / Design Patterns Development and Delivery • IDE mastery: IntelliJ, Eclipse, etc. • Code Reviews / Pull Requests • Testing: Unit testing, test coverage • Effective Debugging / Using a symbolic debugger * Working on an Agile Development team ...

http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ Engineers are hired to create business value, not to program things: Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs. Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things. (That can, but does not necessarily, entail actually doing them.) The person who has decided to bring on one more engineer is not doing it because they love having a geek around the room, they are doing it because adding the geek allows them to complete a project (or projects) which will add revenue or decrease costs. Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals. ...

I’m rolling off a 16 month stint as the sole proprietor of a Java library used internally where I work. Yep, it was an almost unheard-of situation within corporate America: I had no project manager, no marketing rep, no support staff, no unique testers. I was responsible for API design, test plan, interfacing with multiple teams, delivery, support, infrastructure. The works. In short, I loved it. I loved getting to code 6 to 12 hours a day, every work day, working through design decisions, collaborating with other teams. I’d go to bed noodling on design problems, I’d often get insight into them over coffee, then I’d have them implemented by that next night. Most of the people I worked with were colleagues of mine from way back. My only mandate was “make them happy,” and take care of my own stuff. I had a project manager for the first month or so; once he was satisfied I had my stuff together, the reigns were off. ...

I’ve been part of two SCRUM rollouts so far. One was a grassroots effort, the other organizational. I have some thoughts I’d like to share, in no particular order. It’s no silver bullet. Repeat that last sentence 10, 50, 1000 times until you believe it. If your work habits, talent, training, and support roles suck, your (insert work product here) will still suck using SCRUM. On the bright side, you’ll understand that in 2 weeks to 2 months, instead of years after the product is in the field SCRUM teams: 10 people max, and that’s pushing it. Five is better. I was on a 6 person SCRUM team, and it was great. Team of Specialists versus Team of Generalists? I’ve no idea. I’ve arguments for either approach, and no one answer fits everywhere. Yay, “It depends.” I could be a consultant. The team must see the value in SCRUM. It’s a lightweight process, but it requires them to think and communicate on a level they haven’t before. If it’s a drag AND they have to communicate to one another, they’ll abandon both. Don’t B.S. the acceptance criteria. If you don’t complete a user story, you don’t get credit, period. This sort of boundary helps focus the SCRUM team when it’s committing to a story. Enable the team to organize itself once it’s gelled. Yes, that means kicking the dead weight overboard, too. Empower the SCRUM master to do his/her job. Measure if s/he does it. Project Manager != SCRUM Master. The skillset and attitude is different. For heaven’s sake, DO NOT MAKE THE TEAM LEAD THE SCRUM MASTER. I was a team lead and a scrum master for about 2 weeks. Disaster ensued, and I got help for my team. Basically, anything that lets the team lapse into a parent/child relationship will destroy a SCRUM team–they must feel like they have the power to make something happen. Some things that I don’t think SCRUM wholly solves (nor seeks to, if you seek a cop-out): ...

User story: As a developer, I want to tag my code every so often, so that other people can get code that’s stable, not bleeding edge. This is the classic CVS usecase: Commit your code, and then tag it as ‘Production’ or ‘Released’ or whatever. In CVS, that entails touching every file. In Subversion, that’s a constant-time operation you can do wholly on the server. Let’s say you want to copy your current /trunk to /tags/release-1.0 tag. Issue this sort of command ...

Quick hits on a few things: * Quote of the Day: “We have two speeds of development: Fast, and Scalded Dog. Which is appropriate here” (no, that was NOT LXK ;-) ) * It’s a fabulous day outside, if you’re a duck. And, it’s supposed to snow tonight. What month is this, again? * Thanksgiving: Looks like we’re doing the Combs/Brentzel shuffle again this year. Thursday at the Combs family. Friday at the Brentzel clan. ...

Did you say distraction? Here I am! Was kin… Jeff Roberts - Nov 1, 2008 Did you say distraction? Here I am! Was kinda jazzed that everyone’s coming to us for Thanksgiving this year until I realized that meant a couple of nights of housecleaning!

- “So, don’t you think that’s a requirement for being a software developer: Being detail-oriented?” - “Perhaps I’m a bad software developer, then.”

We had a share-session on Polyglot programming the other day, after Mark returned from SDWest 2008. Tonight, I had an evil thought: Half of these languages are ones most in the audience have neither seen nor played with–what if you added some “trick” language names to the slides to see how full of crap your audience was. It’s a play on the same allegory from “The Emperor’s New Clothes”: “…yes, and so your application logic should be components written in a systems language like java [sic], with the higher-level being in a dynamic language like JavaScript, Ruby, or Dimebag.” ...