When I got my first job in software engineering, my team was anything but agile. I was shown my desk, allocated a computer, and given a book to read, Working Effectively with Legacy Code. I devoured it, as well as a few others that happened to be at my desk as well. Everyone I worked with had read these as well. I only took a few computer science courses before I began my career, so, I really hadn’t noticed the existence of books about software as a concept, just how to program in particular languages. This abstract kind of text really spoke to my history in philosophy, I took other recommendations and loans and read quite a few such books. I noticed a shift, people were talking more about articles, and less about books, then it seems no one talked about reading much anymore. This might be more a function of my surroundings changing, rather than the community at large, but I think it’s worth taking a step back.
When we decided it was time for our daughter to learn to ride a bicycle, we did the expected thing and got her a Cinderella bicycle, training wheels included. She was an eager student and we got her going quickly. While she could easily get down the street, turning was very slow and the falls were made more violent by the training wheels creating fulcrum for the bike to tip over. I raised the training wheels to give the opportunity to balance with both off the ground and turn more easily, but still provide some guardrails to prevent tipping. But it just didn’t happen that way, she was comforted by the feel of the training wheel on the ground, meaning she was leaning on the verge of falling by default! I finally talked her into trying without the training wheels at all and I would run along side. With no training wheels to feel, it didn’t scare her when they weren’t on the ground. She did great and rarely fell after that. When it was time for our second child, I got a bike from goodwill and removed the drive train, just wheels and brakes, no cranks or pedals. (they call this a strider bike now) I just had to hand it to her and say, “go” and she was riding all over. After a short while, I either got another bike, or put the pedals back on, I’m not sure which, but she didn’t have to overcome the balancing fear, she just had to learn to pedal and it was pretty much instant success.
Once your code is born, it’s tumbling towards legacy. Developers are licking their chops at the thought of refactoring or making your brand new, beautiful code obsolete, or simply ignoring its existence until it gets cleaned up like so many out of scope variables.
Does that mean it should be built with the integrity of a paper plate? No! Follow me and I will show you the way to keep writing good code without feeling the anxiety of a new parent watching their child begin to walk, freeing themselves to fall gasp.
I love the language of “landing” a job, I’m not sure if it originates from fishing lingo, but that’s how I hear it. Job-fishing seems so much more appropriate than job-hunting. When you are fishing, you often don’t know much about the fish, what kind it is, if it will be delicious, how big it is, if it exists! Hunting is so much more straightforward, you find the prey and take it, the prey doesn’t consider your value proposition and make a decision. I don’t mean to say hunting is easy, you may not find your prey at all, or they may smell or hear you coming, despite your best efforts. But fishing is almost an agreement with the fish, I’m offering this tasty morsel, will you accept it? The analogy definitely has some holes. The job-fisher is hopefully offering the real thing and not a hook wrapped in feathers, though to be sure there are some job-fishers doing exactly that.1
Since you asked, here’s my take on automated responses to job applications…
It’s fine to let the ATS send notice to the applicant that their application was rejected, if it meets these criteria:
There was no phone call
There was no interview
There was no instant message, email, or text exchange
If there was any personal interaction, there should be a personal message. It should include a reason, and a hint as to how to proceed. Ideally there would be some indicator that it really is a personal message, such as a reference to something from the conversation. If you really want them to keep applying to the company, suggest what title or department they should be pursuing. If you don’t think they will fit in, wish them the best in their search. Don’t give false hope, it results in them actively wasting their time.
I recently took a Beer Judge Certification Program (BJCP) tasting exam, I had some time before the exam started to reflect on things. I was thinking, “I drove 2 hours to get here, the test is 90 minutes, it’s before lunch and I’m about to sample 6 beers. Why would I want to do this.” The simple answer is that I want to attain the rank of National Judge, and my tasting exam score doesn’t qualify me for the written exam, which is required for National and higher ranks. But, why would I want to do that, why would I want to be a certified judge at all, or even, why would I want to judge a beer in the first place!
After changing my resume format a bunch of times, I decided to separate the data from the
presentation and use Hugo to render it. I’ve been using this for months and really prefer
it to fiddling with a word processor. Not that fiddling with CSS is so much better, but
it’s really nice to have my list of skills static while I fiddle with how they are
presented. Not to mention, I can separately view the history of how my resume looks and
the history of what it contains. Another big benefit is that, I can write the page
templates in such a way that they dynamically handle a list growing, shrinking, or
disappearing altogether, which can definitely be a hassle in a word processor when you
least expect it.
I’ve tried many methods of planning my days and keeping track of tasks, both paper and digital. For appointments, small recurring tasks, or something far in the future, I use an internet based calendar (intentionally not endorsing one, yours is fine, I’m sure). For everything else, I’ve landed on handwritten notebooks. I have an e-ink tablet that I love for taking notes, but it’s not really part of my system, there are a few things I use it for, like drafting this post, but there’s a little too much friction to use it the same way I use physical notebooks still. I keep two notebooks, separating work and personal (details for stationary nerds at the bottom). The personal notebook might have a little work in it, especially if I’m traveling. The work notebook might have a little personal in it, if I have personal business interfering with my work day. Generally I keep them well separated.
If there is one thing that turns me off when having a technical discussion, it is
when someone utters that some presented solution or capability is impossible.
This is like burying your head in the sand. Not every idea is a good idea, but
generally they are all possible. The promise of technology has always been to
make things happen that we previously thought to be impossible. So the freedom
some feel to say that something is impossible is shocking. I am an unapologetic
optimist, but that’s not the guiding principle here. The sibling of this mistake
is the idea that because you have deemed a solution “possible” that it should
be done. There are reasons not to take every action, and if you can’t find one,
keep looking, it might be a doozy. Too often discussions are ended because of a
lack of imagination, the world is full of possibilities and bad ideas, they are
often the same thing!
I completed my first ultra-marathon a little over a week ago at the Black Canyon Ultras.
It was 50 kilometers (which, to answer almost everybody’s first question, is 31 miles) of
rocky, dry, rarely flat desert trail. It was hard to finish, it was hard to train, it is
hard to express running this race, but I’ll try. For the uninitiated, or the fast, “race” for me,
simply means a group run where you pay in advance and get timed. The racing aspect is left
to a fairly small group at the front, though all of us may want to beat someone at some
point in the race.
A few times in my career, I’ve decided to have a blog. This is another one of
those times. It has been a while and my old Jekyll page was looking pretty dated.
I deleted the old page and have imported all of my old posts, which aren’t very
many, and I made the decision not to even read them to see if they had any value.
The titles look pretty solid though!
One of the great things about computers is that you don’t have to delete anything
you can write the same shell script 100 times with 100 different names and keep
them all. But just like your garage, the more things you save, the harder it is
to really find what you need. So, when you realize that your clever directory
just for scripts that help with parsing log files is totally unused, take a few
minutes to look through and see if any of them are generally useful, and delete
any that aren’t. Then delete the folder. Do this often and things will generally
stay pretty organized.
getting the work/work balance right (or what to do with your overtime)
A lot of people in the tech industry don’t know how to stop working. This is a personal demon each person needs to take care of. The best thing to do with your free time is enjoy yourself. It’s good for you and your employer for you to unwind when you aren’t obligated to be producing. But, if you find that you feel like doing the kinds of things you do at work in your free time, do it, but don’t do work. Find the same stuff to do, but not for your employer, this has the amazing benefit of getting yourself to learn something that is not in the scope of your current projects, while still practicing some of those skills you need at work. It will make you better at what you are doing, and you might even find a better job accidentally in the process. The other side of it is, when you work overtime, you set the expectation of overtime, which can lead to disappointments when you actually don’t have time for it.
Keeping your code portable with Maven dependency scope
If you, as you should, try to keep your code portable by avoiding imports of implementations of standards, such as JAX-RS, JPA, or Bean Validation, you might find yourself accidentally importing the wrong packages, because they are both on your classpath. It is all to easy to accidentally bring these dependencies into your code, they frequently have the same name and the compiler will suggest them. Maven has a clever parameter in the dependency model that many don’t know, don’t use, or don’t understand. It’s called scope and is a familiar term to programmers, but they seem to forget that maven dependencies, as with variables, you should try to limit their scope. The names of the scope aren’t very intuitive, but they make sense with a little thought.
An at work happy hour gets people talking, one or two beers will keep them from worrying about what is important to say and they just say whatever they are thinking. Companies that don’t have the social thing down are not doing it right, the onus of communication is not so much on the individual as it is on the organization itself. If you tell somebody that they need to share what they’ve found, you need to also tell everybody else to listen to what they’ve shared. If you give some folks a ton of free beer, they will find out what the other people will find out what they’ve been up to.
We get warned a lot about going after what’s new, for the novelty of it. But new things don’t come from the ether, they come from people being unsatisfied with the current offerings. So, we know that the new thing is at least an attempt to move forward, whereas the old thing is just the old thing. You might be able to move forward with the old thing, but just because it’s the old thing doesn’t mean you can, anymore than it being the new thing means that it will be worse. There are a lot of old things worth keeping for a lot of reasons. I don’t need to defend those, status quo is self-defending. I would like to speak in favor of the shiny new thing and in favor of migrating to it.
For standardizing across projects, guideline documents are great but even better is when there are processes in place to get things started reliably in line with guidance. Eclipse has code templates and style settings that can make your code perfectly formatted, but it doesn’t do much for project structure, naming and standard configuration. That’s where maven archetypes come in. It is satisfying to automate processes that you know are only minor modifications on previous work, so when you find a project that you feel in your bones will be duplicated, take it upon yourself to make it worth copying, and easy to copy, create an archetype! When you are inevitably asked how to start on a project like the one they heard you worked on, you can tell them, “Run the archetype and you will have all the grunt work done, then you can do the programmer part.” Then when they ask follow-up questions, you are already a little bit familiar with the project.
After changing my resume format a bunch of times, I decided to separate the data from the
presentation and use Hugo to render it. I’ve been using this for months and really prefer
it to fiddling with a word processor. Not that fiddling with CSS is so much better, but
it’s really nice to have my list of skills static while I fiddle with how they are
presented. Not to mention, I can separately view the history of how