For the past several months, I’ve joined the fast-paced and exhilarating world of the CDRH dev team! Here are some reflections from that time, in no particular order.
- Working on multiple projects keeps things interesting from a content perspective, but it can also be very helpful for development. You’ll often find something in one project’s code or setup that you can use in another—or you just get the benefit of approaching the same problem from a different angle.
- I confess that I have never been a fan of the word “team” (did you know in one early meaning it referred to the actual piece of equipment that was used to yoke oxen or horses together, forcing them to move as a unit? See Oxford English Dictionary, “team, n.” definition 5a.) I will, however, admit that dev depends very heavily on other people, their experience, and their willingness to answer questions. I am endlessly grateful to the other developers for their patience and good humor, and to Slack for the parrots. (Could we be a pandemonium instead?)
- Documentation: oh, heavens yes. Let me tell you about the number of notes, process documents, and troubleshooting files I generated in the past eight months. With this work you inevitably run across the same problem multiple times, but it probably has been two months or more and unless you have the memory of an elephant you’ll have forgotten your fix. So: write it down, or rather type it out, and make sure you include any language about the error that would make it more easily findable. You’ll thank yourself later.
- If you also organize this documentation logically and put it somewhere sharable, particularly before leaving a position to pursue work elsewhere, people who follow in your footsteps will praise your name in the strongest possible terms.
- Occasional cleverness and self-deprecation in comments are always appreciated (though of course should not triumph over clarity: all things in moderation). It’s good to know, across time, we are in this ridiculous pickle together.
- Be sure to clear some space in your office, if ever you can, because girl you will want to prance like a cartoon coyote when something works after long hours of frustration and error.
- Find you a notebook, and then find you a larger one, or pick a password manager, because your life will consist of passwords upon passwords upon passwords. And there’s no point in remembering them, because they’ll be too long, or you’ll have to use special characters, or you’ll be prompted every month to create new ones, or in a spaced-out moment before drinking coffee you’ll type them into the command line and they’ll be in the log forever, so you’ll have to change them.
- Prepare to spend much of your life climbing up and down stairs to retrieve the device you need for two-factor authentication.
- Celebrate when an error contains a long word or one you do not understand, for that makes it all the better to Google with.
- Love but do not trust Stack Overflow.
- Some days Git will make you gnash your teeth, throw wild punches into the air, and curse your neighbor. Other days Git will be the most astonishing and wonderful and user-friendly invention ever dreamed up in the world of code and you will want nothing so much as to buy its makers a beer.
- It is never wise to code before coffee.
- Related: fuzzbrain coding takes about 10x as long as clearbrain coding to achieve the same result. I found it helpful to build in breaks and have other kinds of things to do. Often a solution to a problem came not by hacking away at it for hours, but by going for a walk and thinking of other things, at which point suddenly there it came, the answer, right out of the clouds!
- Inevitably sometimes you will feel like the slowest and most foolish and least technologically competent slug that ever lived. It is important at these moments not to succumb to despair. Sometimes you just need to step away and come back another day for a fresh look. Other times you have to slog doggedly on until suddenly you take out a stray quotation mark and everything works like it was always meant to do.
- Another reason to take breaks is you could seriously build a whole new operating system or write a new programming language trying to fix something that turns out just to be a missing parenthesis.
- When you code in Ruby you will be thinking of Python. When you code in Python you will find yourself missing Ruby. Just as you would like to throttle the human who put the “s” in “elsif,” so too you will want to hug the human who invented “to_s.” For every programming language, there is a season, a project, a task, or a use case. Some languages are better at some tasks, however: I found Ruby’s libraries and methods (Nokogiri, e.g.) to be better suited for parsing XML than Python’s, for instance.
- There are almost always multiple ways to do the same thing. If you, like me, are perhaps not the slickest programmer, some of these ways may be quite lengthy. But as with writing, it’s getting the first draft out that matters. Do not be paralyzed by pursuit of perfect code. Often things can be rewritten more efficiently (or refactored) later.
- With thanks to a teacher of Python: very often it’s a good idea to write out what you want to happen in English (or whatever your non-machine language may be) and make sure you’re clear and detailed about the various steps before trying to make it happen in code.
- The machine may seem arbitrary, capricious, and full of spite, but it is almost always doing exactly what you told it to do.
- Beware lest ye write 250+ lines of conditional code to handle something that could be resolved by changing data in 4 files.
- Go ye not too far in any direction before developing a good understanding of the data.
- Regular expressions will vex your soul, but they make everything possible. Testers like regexr.com are great ways to make sure you’re actually grabbing the thing you think you’re grabbing (see in particular that website’s “Cheatsheet”).
- You can make many things happen without totally understanding the code, and sometimes it’s necessary to move forward without understanding the minutiae of how everything works. That said, slowing down and taking the time to learn some fundamentals can REALLY save you time later, and give you a much clearer sense of what’s happening in a framework at a broader level.
These are some of my takeaways, anyway, and maybe one or two of them will help you, too. The most important takeaway is this is a fine group of people and a fascinating set of projects, and it has been a privilege to work with them this year.