What do you really get from IDE-driven development?

The author reflects on why development with an IDE is not that useful. In effect, it creates a local maximum that can trap you into thinking it’s a global maximum.

In effect, as my friend experienced in his coding class, these sorts of things don’t make better programs and don’t make us better programmers. We end up knowing less than we should and get less than we deserve.

I’ve never warmed to IDEs myself. I’ve typically found them too constraining and wanting to take over all of my development workflow at once: How I setup my project, how I declare dependencies, how I setup my tests, how I compile my code. It feels like an all or nothing affair. I’ve long¹ preferred a programmer’s editor: Syntax highlighting, code navigation, and the ability to automate when I want it.

That Wild Ask A Manager Story

This article references a story that was new to me: The person interviewed is not the same person that shows up for work. This author’s takeaway is interesting. Instead of overreacting, he would do nothing:

The premise here is simple: designing a human process around pathological cases leads to processes that are themselves pathological.

The UX on this Small Child Is Terrible

This is pretty funny. Reminds me of Introducing JIRA Jr. Project Tracking… for kids

In Defence of the Boring Web

I made the exact same decisions as the author to create this very website: Markdown source, a static site generator, little javascript (in my case none), and a minimalist theme. However, I don’t think boring is a good word. My dictionary defines it as:

not interesting; tedious: I’ve got a boring job in an office.

Instead, I would use a word that connotes tried-and-true, simple, adequate for the job. Reliable comes to mind.

On the Various OSS Fauna

I didn’t know about WikiFauna. I like the idea a lot: To outline the different roles that people can take to contribute to the project. I am not sure about fauna as a term, or that calling folks elves, cyclops, fairies, gnomes is useful at all.

Nate Berkopec does a great job in adapting the idea to OSS and correctly points out that most OSS is volunteer work: You decide your level of involvement.

It seems that nowadays everyone is playing Wordle. And for good reason. It is a lot of fun! There is an evil variant, Evil Wordle that is, well, evil:

There’s no word set by default. Every time you guess, I look at all possible 5-letter words that would fit all your guesses, and choose the match pattern that results in the most possible words. My goal is to maximize the amount of guesses it takes to find the word.

Let’s play with unix tools at our disposal. To be on the same playing field, I took a peek at the source in the browser, and downloaded the list of words that are part of the game dictionary:

Programmers Should Stop Celebrating Incompetence

DHH is well known for kicking up a storm. I don’t always agree with him. In this case, I do. We can strive for competence and embrace newcomers to programming. Software challenge us to learn new things all the time, but that doesn’t mean that we don’t know anything.

Against my better judgement to never look at the comment section, I glanced at some of the reaction on Twitter. A lot of the objections seem to be saying “Stop telling people they can’t look up things on the internet”. Example:

You must have everything you need to know to do your job memorized You know, like doctors and lawyers and mechanical engineers Riiiight

DHH didn’t say any of that. He said that you should be working to improve your knowledge in the areas that you choose, and not pretend like no one knows anything.

Be Curious, Not Judgmental

It is tempting to trash others work and belittle it. It can make us feel bigger, smarter, better. It is not conducive to learning and deep insight. If instead we adopt a curios mindset, the results can be quite different. The post illustrates the point well.

How to rest well

This post by Alex Soojung-Kim Pang reinforces my belief that rest is a competitive advantage. Being well-rested improves cognition. Downtime, and time for hobbies is important and should be prioritized. “All work” is a terrible mindset.

Oj is a Ruby gem that bills itself as a faster way to generate JSON, mainly through the use of a C extension. I recently found it was generating unexpected results.

I was looking through a report that one of our endpoints was generating unusually large JSON payloads. In particular, timestamps where being serialized to a very verbose (and not very useful format):

{
  "created_at": {
    "^o": "ActiveSupport::TimeWithZone",
    "utc": {
      "^t": 1639339673.031328000
    },
    "time": null,
    "time_zone": {
      "^o": "ActiveSupport::TimeZone",
      "name": "UTC",
      "utc_offset": null,
      "tzinfo": {
        "^o": "TZInfo::DataTimezone",
        "info": {
          "^o": "TZInfo::ZoneinfoTimezoneInfo",
          "identifier": "Etc/UTC",
          "offsets": {
            "^#1": [0, {
              "^o": "TZInfo::TimezoneOffset",
              "utc_offset": 0,
              "std_offset": 0,
              "abbreviation": ":UTC",
              "utc_total_offset": 0
            }]
          },
          "transitions": [],
          "previous_offset": {
            "^o": "TZInfo::TimezoneOffset",
            "utc_offset": 0,
            "std_offset": 0,
            "abbreviation": ":UTC",
            "utc_total_offset": 0
          },
          "transitions_index": null
        }
      }
    },
    "period": null
  }
}

I quickly saw that the controller was invoking Oj directly, and that is the root of the problem. The library has a Rails compatibility mode, that is not the default:

ts = Time.zone.now

ts.to_json
# => "\"2021-12-12T20:10:56Z\""

Oj.dump(ts)
# => "{\"^o\":\"ActiveSupport::TimeWithZone\",\"utc\":{\"^t\":1639339856.001998000},\"time\":{\"^t\":1639339856.001998000},\"time_zone\":{\"^o\":\"ActiveSupport::TimeZone\",\"name\":\"UTC\",\"utc_offset\":null,\"tzinfo\":{\"^o\":\"TZInfo::DataTimezone\",\"info\":{\"^o\":\"TZInfo::ZoneinfoTimezoneInfo\",\"identifier\":\"Etc/UTC\",\"offsets\":{\"^#1\":[0,{\"^o\":\"TZInfo::TimezoneOffset\",\"utc_offset\":0,\"std_offset\":0,\"abbreviation\":\":UTC\",\"utc_total_offset\":0}]},\"transitions\":[],\"previous_offset\":{\"^o\":\"TZInfo::TimezoneOffset\",\"utc_offset\":0,\"std_offset\":0,\"abbreviation\":\":UTC\",\"utc_total_offset\":0},\"transitions_index\":null}}},\"period\":{\"^o\":\"TZInfo::TimezonePeriod\",\"start_transition\":null,\"end_transition\":null,\"offset\":{\"^o\":\"TZInfo::TimezoneOffset\",\"utc_offset\":0,\"std_offset\":0,\"abbreviation\":\":UTC\",\"utc_total_offset\":0},\"utc_total_offset_rational\":null}}"

Oj.dump(ts, mode: :rails)
# => "\"2021-12-12T20:10:56Z\""

Adding mode: :rails to the Oj call fixed the unexpected payload size issue.

The fact that we had a production endpoint generating unexpected JSON for months lets me know two things:

• There is no test coverage that checks the generated JSON against a known schema
• Consumers of this internal endpoint have no use for the timestamps that were being sent down: There is no code that recognizes that data structure.