Andrew Yurisich a collection of things

Use Zero for Every Numbered List in Markdown

Here's a simple habit that can make working with numbered lists in markdown much simpler, especially if you're still mentally figuring out the order of the list as you're typing it.

Typically, numbered lists in markdown are demonstrated in a simple, straightforward fashion.

1. A list
2. Where order
3. Matters greatly
4. And could change
5. In the future

Now, should I need to add a step that I forgot, I'd have some unneccessary editing to do.

1. A list
2. Of important things
2. Where order
3. Matters greatly
4. And could change
5. In the future

The second two becomes a three, the second three becomes a four, and so on. It's a subconcious thing -- I believe that most writers have a desire to number their lists appropriately, and will want to see them fixed right away. It hinders thinking if the list is numbered incorrectly (at least it does for me). Once the list looks pretty again, thinking resumes. And now, another entry is placed between numbers two and three, and the cycle continues.

Here's a better way.

0. A list
0. Of important things
0. Where order
0. Matters greatly
0. And could change
0. Very easily
0. In the future

This will render as the same numbered list, and appears as a neutral "increment" value of zero. Of course, inserting or rearranging this list is trivial.

Uptown Special: ★ ★ ★ ☆ ☆

Cover art for Mark Ronson's 'Uptown Special'

This review is dedicated to my brother, who got me a copy of this album, urging me to listen to it. I wasn't supposed to judge it, and simply listen to it with an open mind and let him know what I thought. I did, and I guess the best way I can think to prove this to him is to write a review of Mark Ronson's latest release, "Uptown Special".

Before I begin, there are two things you should understand about my music listening habits, both of which are likely attributed by my upbringing preforming classical violin in middle school and high school. First off, this album is far too new for me to be listening to it, being that my standard is to wait anywhere between 9 and 12 months after an album is released before spending any time listening to it. When you are spending large chunks of your free time rehearsing 200 year old music, listening to music from three years ago is suddenly so new, even if the rest of the world has long moved on.

This can also be really helpful in cases where critical reviews are dominating search engine results immediately following the release, which can muddy my perception of the album after reading another's take on it. This is a big deal to me. Had I listened to, say, King of Limbs right after release, I probably wouldn't have given it more than two or three listens before succumbing to the temptation to "supplement" my opinion with that of popular sources' review.

However, I waited about a year, allowing me to engage in my second odd quirk in my listening habits, again, forged by my years in the orchestra. I listen to the same album (or sometimes, a group's entire catalog) for, on average, four to six weeks. I work in software development, and in that capacity I spend a typical day with about five hours of solid listening time. To be conservative, I've listened to this album, on repeat, probably 100 times. I have sonically etched this album into my brain's auditory stores, available for high-quality playback for up to six months. All I need is a quiet room and a little bit of time. So I feel my opinion on this album is coming from place beyond a simple "impression" review and more "I have this album basically memorized".

You may wonder how the math adds up there, for those who decided to do a quick back of the napkin estimate of my claims of listening to this album one hundred times. The album is much too long to listen to that many times in two weeks! You're right, it is. However, I didn't listen to the entire album one hundred times. I listened to the entire thing maybe twenty times or so. After just a few days of listening to this album, I decided to cut out some tracks that I felt were added simply to justify the album's existence from a production standpoint. Those tracks were conveniently located in a cluster; tracks three, four and five.

It really upsets me that the smash hit single of the release, "Uptown Funk", has, at the time of writing, nearly 184 million views on YouTube, while many of the really engaging parts hang in at around two thousand hits each. I mean, sure, I get it. You have to have something that will catapult the rest of the material into a place where it can get produced, publicized and performed, and in that sense Uptown Funk does a great job doing that. What it doesn't do a great job of is fitting in with the rest of the album. Speaking of that, Mystikal's half-stepping insult to James Brown's raspy style is so far removed from the other tracks as to be utterly dumbfounding. Rounding out this trio is an overly intense, too-disco sound of "I Can't Lose". With these, you have what record executives call a solid offering, and what a Pulitzer Prize winning author and lyricist calls a distraction.

What I can't understand is, if the album has a supposed R&B influence of the 70's and 80's, why does that influence only appear on the tracks that don't seem to fit in with the rest of the album? Why does the rest of the album sound like it was made by a progressive rock band with a good ear for electronic interludes? Why do the lyrics go from parties, dancing, and a general sense of being a standard pop record to entering very strange world of reflecting on your deserted upbringing in privileged Los Felix, New York? This becomes more troubling when the rest of the album pushes on into a life of gambling, prostitution, and dealing heroine in Las Vegas.

This album sounded like it set out to be a very bold, ambitious abstract on living a questionable life in the desert, and ended up being half of that with some pop singles tacked on. What a disappointment. If you have a haunting interlude by Stevie Wonder sprinkled throughout your album hinting at some serious trouble nine exits North of Las Vegas, you shouldn't squander that with cheap grabs at the Hot 100. But who am I to judge. Without those singles, I probably wouldn't have found this excellent group of eight tracks, a solid 27 minute ride that will definitely stay on repeat with me for at least the next few weeks. If I were to review just those eight tracks, this review would easily earn four stars out of five.

Favorite Tracks:

  1. Crack in the Pearl, Part II.
  2. Leaving Los Felix
  3. In Case of Fire

If you liked this album (namely, the parts I didn't delete from the track listing), you might enjoy Miami Horror's Infinite Canyons.

Staying Sharp in Software Development

This is my fifth year writing software. As I continue my development in the trade, I find myself spending more and more time interacting with people who's level of contribution now exceeds that of an "individual contributor". They are much too talented to be writing any more code, so their superiors would like to say. Their time would be much better spent discussing the problems that some given software is trying to solve, and ideally, never write any to begin with. In those cases where software is needed, they spend their efforts scaffolding out initial solutions, architecting the patterns for others to fill in with details. I would argue that these all play a part in a successful version of the software development life cycle.

I have no issue going on the record by publicly stating that I have no interest in being a member of this group. In fact, I'll go as far as saying that the only way to stay truly sharp in the ever-evolving world of software development is to periodically reset your career to that of a junior hire every couple of years. Any analogy that you might construct to convince me otherwise is likely to apply poorly to writing software. We are not generals in a war, where "boots on the ground" can't be wasted on the likes of our best and brightest. Oftentimes, there isn't a clean way to truly solve (or even understand) a problem without becoming the entry-level developer who invariably gets tasked with that whole "details" part of the process. I find it odd that we leave our best and brightest to identify the obvious parts of the problem, while leaving the costliest, most error prone mistakes to be made by those who are in the prime of their mistake-making part of their careers.

For an example, take the common case: business software. At the highest, highest levels, there is a need for some payroll system to be put in place for a new company. For someone at a director level, there is a tax issue preventing them with going through a typical payroll servicing company. For an architect, there are tax disadvantages by using pre-fabricated payroll software, so it'll need to be coded in house. At this point, much of the hard work is done, in a sense. The only thing left is to actually make that list of exceedingly more detailed requirements into the most detailed requirements — computer software. Compare this with something like research, where those at the highest levels decide there is a practical business need to build self-driving cars. A director discovers that the technologies behind this don't exist yet, or at best, are new, unvetted, and rough. Where do you begin with those requirements? No amount of architecting can suddenly make computer vision easier. Those are hard details, and they must be orchestrated in a way that makes sense when conforming to something as massive and complex as the motor roadway laws of California.

A great developer will be able to see the forest through the trees, while running through it with a group of four people. Obviously, you can't do it forever, but again, many analogies fail here. It's a lot like hunting, except the barrier to exit is much, much lower. You can be a great hunter, and know where the biggest game tend to gather, but your insights will only take those doing the actual hunting so far. When you're no longer the one stringing the bow, it's easy to forget that the hardest part of hunting is "don't miss". If you find yourself suddenly supporting a village too large to do the hunting yourself anymore, it may be time to start designing better bows and arrows for them to use.

What do you have to lose in a skill like software development? Your ability to type? Your eyesight? Those things last for seventy years or more in a healthy citizen living in a first-world country. The only major loss you face as a real threat is your ability to stay active in a world that is dominated by the new technologies, authors, tools and workflows that can too easily slip from your grasp as you become too senior of a developer.

The Wolf of Wallstreet: ★ ★ ★ ★ ☆

Poster from the movie 'The Wolf of Wall Street'

What impressed me most about this film is that the book it was based on was written by Jordan Belfort, further proving that you can get rich writing a book about getting rich. Although the gratuitous nudity and drug use make it difficult to publicly recommend, the charm of a rags to riches story is certainly enhanced here by revisiting the rags, and the trip back and forth is conveyed with plenty of style.

I felt Leonardo DiCaprio's performance was judged too harshly by those saying he over acted in hopes of sealing an academy award in his rendition of Jordan Belfort. The beginning of the film, which features his character working through a brief stage of worldly naivety, is completely convincing and serves as a stark contrast to the middle of the film, which left him barely recognizable in my eyes. That alone demonstrates his versatility in portraying both the pedestrian sections of the script, as well as the "Oscar baiting" scenes.

In terms of what could be improved, the time ran a bit too long at 3 hours. It may have been served some favors by reducing a few of the many pep rallies that went above and beyond in establishing the mood of a money-hungry investment firm. I found myself re-watching parts of the film, but consistently skipping those scenes in particular (or at least large parts of them). I also felt the connection between Matthew McConaughey's character and Leonardo DiCaprio's character was too thin to keep re-establishing throughout the film. Perhaps if his mentorship had grown past anything but a single drug-fueled lunch, I would have less of a problem believing the impact it had on Jordan's development throughout the film.

Alternative Github Tags

Most github users are aware of tagging issues and pull requests to organize them better. Some also know that it's a good idea to create your own tags to suit your team's individual needs. Our team uses some tags that help deal with communication in larger projects with many collaborators. They're not the usual permanent issue labels, but rather, stateful indicators that alert teammates what the status of a pull request is at a glance.

The Background

Like many experienced git users, I make branches for nearly everything. And as an experienced git user in a team-based environment, I tend to stagger those branches to introduce large changes in the following order.

  1. Outline the impact, typically by changing the directory structure.
  2. Submit blank tests that serve as a rough contract of the change.
  3. Write code that would allow the tests to pass.
  4. Write tests.

The advantages of this approach are huge. Pull requests generally hover around ~200 lines added or removed at any given time. Each phase of the full change never breaks any build automation, and if it does, there's an opportunity to discuss the value, the approach, or the technique used at that point, or at any point before it. You can also get a good idea of what needs to happen in subsequent pull requests as you go along. For me, having 700 or 900 lines of code changes in a single pull request is unacceptable (unless you're checking in machine generated data).

The downsides are pretty obvious too — both myself and the reviewer are in charge of juggling possibly four or more pull requests all at once. If there's a typo in the second pull request, I'll have to introduce it there, and rebase all following branches on it again. This can lead to excessive force-pushing, and extra communication with any reviewers who like to check out the code locally as they review.

The Summary

One of the main issues I had with this workflow involved the previously mentioned communication overhead. I'd see three or four of my own pull requests open, and four comments split up over two of them. I'd need to constantly remind myself which branch needed what changes, especially for routine tasks like rebasing against master. We discussed the idea of having tags that don't represent the essence of an entire issue, but rather, the current state of an open pull request.

Eventually we agreed to add the following tags. They've been very helpful for us, and you should consider adding them to your project as well.

  • Pull Request Reviewed with Comments

A persistent "you've got mail" for the pull request. Once cleared, this means the submitter has responded to comments.

  • Pull Request Merge on CI/CD Passes

Helpful for when you want to let everyone know that the pull request is good, and no other actions need to be taken once the automation runs with a clean exit. I've had a great time merging two or three pull requests I knew nothing about this way.

  • Pull Request Needs Rebase

For when a pull request stays open too long and another pull request has been merged ahead of it that makes a conflict.

  • Pull Request Needs Squash

Lets the pull request owner know that they've addressed reviewer feedback successfully, and need to tidy up the commit log by melding all commits into one.

Once any of the above tasks are completed, the submitter removes the tag.

More Traditional Issue Tags

Aside from those temporary tags, here are other handy "traditional" tags to add to your github pull requests.

  • Needs Discussion

A signal for other reviewers to weigh in on a possible disruptive change to the codebase.

  • Large/Small Pull Request

Subjectively applied to pull requests that will likely be prioritized due to its size. It's nice to know which pull requests will take 5 minutes to review, and which will take 5 hours.

  • 3rd Party Version Change

Makes it more apparent to those who review your code locally to refresh their third party dependencies before trying to vet the changes.

  • Breaking Change

Introduces a backwards-incompatible change to anyone depending on the code featured in the pull request.