Jud – Page 30 – Making Of Things

Diligence Is For Lazy People

By Jud | September 29, 2017 | Comments 0 Comment

I wrote yesterday’s post almost a full day in advance, which hadn’t happened before in the (admittedly short) history of this blog. It felt really nice when my daily 9am writing reminder went off to simply click “Publish” and get on with my day, instead of hitting snooze and hoping I get back to it later.

It brought to mind my sophomore year of college, where I learned the value of discipline. My fiancée was at a school ten hours away, and I had a randomly assigned roommate with whom I had nothing in common (and despite his pedestrian physical appearance managed to have three simultaneous girlfriends for most the year, but that’s a different story). I also had a class schedule that finished by 2pm every day.

Since I had little reason to get back to my lonely little dorm room so early in the day, I got in the habit of hanging out in the library studying until dinner. I quickly discovered that this routine completely freed my evenings and weekends of schoolwork. And that was awesome. I wasted gobs of time playing video games during those hours, and didn’t feel the slightest bit bad about it, because my work was done.

It’s Elementary

By Jud | September 28, 2017 | Comments 0 Comment

There are really only two tasks a company must perform:

Make great products
Sell them for a profit

Each employee, no matter her job title or role, must contribute in some way to one or both of those two goals. Any other task is only a means to one of these ends; everyone involved does well to remember that.

And yes, I realize strictly speaking products and services are two different things, but for the sake of pith can we consider the latter a type of the former? Thanks.

Two Days In A Row?

By Jud | September 27, 2017 | Comments 1 comment

Back in my days working for a large defense contractor, it was understood that as a developer became senior she would get involved in writing proposals. At the time I thought it an odd expectation; shouldn’t developers stick to doing what they do best, i.e. writing code?

But now I see the wisdom in getting engineers more involved in the process of winning new business. For one thing, it forces them to write, which is not a bad thing, even though it isn’t always fun. Secondly, it helps build relationships between engineering and sales, two departments which are often at odds (this is probably worthy of its own post, stay tuned for that). Finally, it gives them insight into the kinds of features customers are asking for, and allows them to be a part of suggesting creative solutions for those features.

So yeah, I’m a proponent of proposal writing. And in a completely unrelated note, I’ve got a big spreadsheet of proposal questions I need to divvy up among the team for responses. Who’s with me?

Z Is The Most Important Letter

By Jud | September 26, 2017 | Comments 1 comment

(I’ve been asleep at the wheel for far too long here, time to dive back in with a truckload of mixed metaphors).

Do you get enough sleep? Americans are chronically sleep-deprived, and a body of research is growing that tells us how damaging a lack of rest is to every other area of life (see, for example, this fantastic article). The particularly troublesome aspect is how sneaky the damage can be, manifesting itself in subtle ways over time.

A large part of being a professional software developer is taking care of your meatspace hardware. And that means getting regular sleep. The image of the late-night coding warrior who bangs away at the keyboard until the wee hours of the morning may play well on TV, but it’s false. The most effective engineer is one who rests.

The Bible Of Software Engineering

By Jud | August 28, 2017 | Comments 0 Comment

One of my all-time favorite passages on software development.

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Frederick P. Brooks, The Mythical Man-Month

The Name Of Things

By Jud | August 21, 2017 | Comments 0 Comment

If you cannot say the words, you cannot solve the problem.

This is true of many subjects in the world right now, a crippling inability to call things what they are. But it is also true of software development. I’ve written before about the importance of accepting blame when something goes wrong. The first step of that process is being willing to say what went wrong, to name it with precision. Shortly thereafter the people responsible for ensuring that particular thing doesn’t go wrong should be named, not to shame them or make them feel bad, but so they can be given the opportunity to improve in the future.

While it might be easier to “not point fingers”, such an approach rarely helps an organization get better.

The Herpes Of Version Control

By Jud | August 4, 2017 | Comments 1 comment

I love git. Truly. Once I got over the fear of learning something new and dove in, everything else paled in comparison. Maybe it’s just because I was a math major and directed acyclic graphs are cool. Maybe it’s because it everything about it makes sense (kinda like Python in that respect). Maybe because it’s the foundation behind open source software development sites like Github.

But this post is not about how much I love git, or why you should use it over the alternatives. It’s about one particular feature that drives me crazy at times, and that’s tags. Yes those littles things you use to mark important places along the development tree. They’re quick and easy to make (especially by CI tools that vomit them out daily), and really useful to have around. But the darn things are nearly impossible to get rid of.

It’s not that the implementation is confusing or doesn’t have logical justification (it does). But the distributed nature of git means they spread like wildfire, and are incredibly difficult to delete across all cloned repositories. You think you’ve gotten old ones deleted, and then some poor developer who hasn’t cleaned up his repo (or even worse, the local copy of a repo on your CI server) pushes and they all come back. Argh.

For a guy who is as anal-retentive as they come about keeping his repos tidy, tags are just the worst.

Be A Polyglot!

By Jud | July 25, 2017 | Comments 0 Comment

A couple of days ago a colleague of mine was reading out loud some code he was debugging, and I could have sworn he was direct quoting from Execution In The Kingdom Of Nouns.

That story is one of my favorite warnings against the notion that software development is a “one size fits all” proposition. There’s great value in being fluent in a number of tools and approaches, and using the right tool for the job. Can this be taken to an unhealthy extreme? Of course, but in general the benefits outweigh the drawbacks.

Lions And Tigers And Permutations, Oh My!

By Jud | July 20, 2017 | Comments 1 comment

This blog is turning into a bit of a “debugging adventure of the day”, which wasn’t the original intent, but whatever. I’ll get around to meatier posts someday.

This morning’s adventure was debugging a pretty serious issue with a web application where selections would not save. Initially it only manifest itself on Windows machines, so we thought Microsoft was to blame. Oddly, though, Chrome failed to work but Edge was fine. Weird.

Wanting to check a few other variables, we grabbed another co-worker’s Windows laptop, and it worked fine in Chrome. WTF!?! Nearly identical hardware, same OS, same browser, and same browser version, but one machine worked, and the other didn’t. Cleared caches, rebooted, etc. Same results.

But did you catch the word “nearly” there? Turns out there was a difference between the two laptops. One had a touchscreen, and the other didn’t. Fast-forward through an hour of slogging through a bunch of hacked together JavaScript code to support drag-and-drop on a variety of devices, and sure enough, the “non-mobile yet touchscreen enabled” case had its own special snowflake handler that wasn’t working correctly in Chrome.

Why you ask? Well, in some browsers, touch events are delayed by 300ms (this is so things like double-tap and dragging can be detected properly). This causes the mouse click event to go first, and when clicking on a button that submits the form, the form gets processed before the touch event can fire that needs to run and configure the inputs to the form submission. If you touch the button instead of clicking with the trackpad (a condition that only makes sense on a touch-enabled laptop vs a tablet), it works okay.

That means this situation only manifest itself on a touchscreen-enabled non-mobile device, in Chrome, when the user clicks the submit button with the trackpad vs touching the button. Can’t hardly blame QA for not finding that one.

Dirty Work

By Jud | July 13, 2017 | Comments 0 Comment

Developers like to write code, that’s what they do. But being a software professional means working on a number of other tasks, some of which are decidedly un-fun. The wise developer recognizes the importance of these tasks and approaches them with no less effort than their more enjoyable work. Grooming a task list. Writing documentation. Cleaning up repositories. Slogging through a naming refactor to improve consistency. She knows that these will all pay off in the long run.

Yesterday I spent nearly 10 hours working in JIRA, getting my head around nearly 150 tasks that need to get done in the next 3 weeks. Circumstances had forced me to be pretty heads-down in dev-world the past couple months, and my planning responsibilities had fallen by the wayside. I owe the team more than haphazard and vague requirements, and this is the first step to doing better. Here’s to a full July!