Recently, I’ve been running a book club to cover the contents of the Pragmatic Programmer by Andrew Hunt and David Thomas. One of those volumes that has been held up, forever, as a text that any good Software Engineer should have read. The text itself is rather sound, although starting to show it’s age in the era of software-on-the-browser.

Probably not going to do much of an articulated look at the book. Rather, I think I will simply post my cliff notes as I, or we go through each chapter.

Chapter 1

• Take responsibility for actions, career advancement, project, and day to day work while being honest about your shortcomings
• Understand that responsiblity is something you actively agree to.
• You don’t directly have control over the success of things that you take responsibility for.
• You do have the right to not take responsiblity for an impossible task, but if you do accept responsiblity, then you are accountable for it’s success
• Provide options, avoid lame excuses
• “Broken windows” in the code encourage the code base to degrade over time
• “Start up fatgue” sets in when you make a greenfield request too big. Start small, and work to larger
• Keep the big picture in mind to avoid creep
• Software needs to be good enough for the the user; the maintainer, and lastly; for yourself
• Ask the users how good they want their software to be
• Great software today is often preferable to perfect software tomorrow
• Know when to stop making improvements
• Your “Knowledge Portfolio” is your most important asset, but it has a half-life. Invest in it regularly, manage high and low risk skillsets, and keep a diverse portfolio
• Some ideas to keep on top: learn a new language each year (particularly ones that introduce new paradigms), read a technical book each quarter, read non-technical books, participate in user groups and conferences, stay current on industry trends
• You’re communicating only if you’re conveying information. Know what you want to say, know your audience, choose your moment, choose a style, make it look good, involve your audience, be a listener, and get back to people

Chapter 2

• We are always maintaining software, it is a routine part of the development process
• “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” (DRY)
• Wrong comments are worse than no comment at all
• Keep code orthogonal, that is eliminate dependencies such that internal changes in a module do not change the external interface.
• Orthogonal code reduces risk by isolating bad code, allowing for agile development, easing tests, and reducing vendor lock-in
• Avoid excessive team overlap
• When designing architecture, ask if you were to dramatically change the requirements how many modules must then change?
• Develop shy code that doesn’t reveal it’s internal impelementations
• Avoid global data
• Use the stategy pattern to avoid functions with similar bodies
• Do not approach projects with notion that there is only one way to do it
• When a critical decision is made it narrows the pool of future possible decisions; put off such critical decisions until later by making code reversable
• “Tracer Bullets:” start with a small, single aspect of the final system and complete the piece first. Iterate upon that piece to fully flesh out the system. Integrate daily, rather than building a single monolith and then integrating
• Prototyping generates disposable code. Stakeholders must be made plainly aware that a prototype is not a finished product and cannot contribute to the final production product
• Prototypes are creates to analyze and expose risk. They are designed to explore a single aspect of the software
• Use prototypes for things that haven’t been tried before, critical systems, and anything unproven or experimental
• The language of the domain suggests the programming solution
• You can implement the domain language into an interpretive language
• When estimating use the units of the quote to suggest uncertainty, e.g. a project doable in a sprint is quoted in days, a project doable in a month or two in weeks, a project doable in over a quarter, in months, etc.

Giant scattering of random thoughts over the first week using Mastodon:

• God this interface is confusing. Local, federated timelines?
• Local timeline is just everyone posting publically on the instance
• Federated timeline is all posts on the instance plus any posts from federated instances that my instance are interacting with
• This is actually quite fun. The local timeline really encourages me to just reach out, favorite, “boost,” or reply to any public post that strikes my fancy.
• There’s a lot of really great conversation going on, particular about the nature of social media, technology, art.
• Advertising this as a “Twitter” clone missing a lot of the point. This is more like an async or threaded version of IRC. There’s quite a firehose of comments on the local timeline, each inviting me to just hop in and start chatting away on the topic.
• I’m actually having a lot of fun with this, more fun then I’ve had since the old BBS days. The social barrier (the thought that someone is going to judge you for hoping into their feed) is rather low.
• I realize that my initial impression with Twitter was, this is a really boring platform. Everything is empty. The platform is encouraging me to follow some celebrities or news organizations. The emphasis was on becoming a follower high-volume “influencer.” It’s another consumption platform. I quickly felt like if I wasn’t a celebrity or obsessive interested in growing my following then I had nothing to say on the platform and should just shut up and listen. Most of the big names were insipid or posted so much that I couldn’t keep up. It took a long time to fine tune a list of eighty people to follow before I started to find the platform useful. I’ve probably posted more on Mastodon in a week then I have posted on Twitter in the two years that I actively used it.
• People are nice. They reply to your random interjections into their threads. The community is generally friendly. There’s a progressive vibe, but not the kind where people are screaming their frusterations and outrage at the state of the world constantly.
• You know what. Let’s just perma-block Twitter and Facebook. Still need the later for people stuck on Messenger, but if I’m going to be wasting time on a social network, I think I know which one I want to be spending time on. Love that multilingual is the default.
• Traditional social media seems so balkanized – I have to intentionally leave the Anglosphere. As someone whose spent years trying to learn French and Spanish, its nice to not have to intentionally go hunting for it. Love seeing Arabic and the east-Asian scripts as well. Not turning them off. Can’t read them. But seeing them will make me want to try someday. Makes me feel much more cosmopolitan. The internet of the last decade has grown far too provincial. Whereas my early online friends hailed globally – the UK, Finland, Norway, Australia, Japan, France, Germany, Brazil the recent fashion has been to push people into regional or cultural groupings.
• On one hand, don’t worry about federation. On the other hand, its all about the federation. Federation maintains the small community feel. There may be 1 million Mastodon accounts out there, but there will only be a small handful of active accounts on your instance. Names quickly become recognizable. Reputations, interests, etc. mill in much as they would on a small community bulletin board or an active chat room. What federation does though, is allows you or ot her community members to reach out to other instances and invite interesting people to participate in your local conversation. Thus if someone from your instances likes or boosts an article off the federated timeline, then it gets promoted to their local followers. And if someone follows a user from another instance, then that users public posts populate into your instance’s federated timeline. The dynamics of this system were not obvious to me at first, but quickly becomes apparent in it’s ability to create small social hubs, like a virtual pub where “everyone knows your virtual name.”
• One thing that I now realize is just how tense my online precense has become with the fear of judgement, that words flung into the void would come back to haunt me. I have become very precise, almost shy in the expression of ideas. Mastodon brings back a kind of immediacy that melts away very quickly. Rapidly, I am posting off the wall thoughts, engaging in deeper conversations with people, offer to help, doing things that I never imagined on Twitter or Facebook which have both become such public-you-are-a-brand style interfaces

Continuing my deep dive into shell and editor commands to find, useful tools that I’m not taking full advantage. This week is debugging PHP using Vim and XDEBUG.

XDebug in Vim

XDebug has been installed on every development machine that I’ve worked on for as long as I’ve worked. It outputs wonderfully formatted stacktraces and var_dump values. However, the interactive debugger side of XDebug remains little used due to the overhead of setting it up.

When I developed using PHPStorm, the interactive debugger seemed extraordinarily unstable. After taking the time to set up a project, map the directories correctly, configure ports and then trigger the debugger it would run for a few lines then halt. I eventually stopped using it.

The Vim VDebug plugin, running locally on the server seems a much more stable implementation. However, I still use it much less often then I should. Largely, this is due to comfort level. I’m not comfortable enough with it, so I don’t bother triggering it.

Yet, it would be easy to become comfortable. Any time that I want to inspect the value of a variable under an operations, instead of echoing or var_dumping that value out – put a breakpoint, and trigger the debugger. After a while, it will become like second nature to enter the debugger instead of printing the variable. Consequentially, if after inspecting the first variable, I discover the need to inspect a second variable, well the debugger has already started and inspecting the second variable is a zero-cost operation.

Installing and configuring XDebug, I leave to the documentation. Initiating the interactive debugger is done through VDebug, a Vim plugin that works with PHP, Python, Ruby, Perl, and NodeJS debuggers – or as it’s documentation says, any debugger that implements the DBGp standard.

Starting the XDebug Plugin:

Debugging starts by selecting a breakpoint line, navigating to it and pressing <F10> to toggle the breakpoint. Second, we start the debugging session by pressing <F5>. We then have 30 seconds to start the session which can be done in one or two ways.

If accessing our PHP script via the browser, we add XDEBUG_SESSION_START=$ideKey to the URL query string. If accessing our script via the commadn line, we start the script via:

php -dxdebug.remote_enable=1 \
    -dxdebug.remote_autostart=On \
    -dxdebug.idekey=$ideKey \
    -dxdebug.remote_port=9000 \
    some-script.php

Where $ideKey by convention is the unix username and port is 9000 or whatever port XDebug was configured to use.

Debug controls:

When to Step Over, Into, or Out

The step over, into, and out of always tricks me up. First, contrary to what I thought, you can’t use step-over to step over loops. They only effect whether you are stepping into, over, and out of function or method calls. Essentially, if a function is to be called on the line under evaluation if you step-into it, then we step into the function and debug line by line that function. If we step-over it, then the debugger executes the function and takes us to the next line in the current context. Step-out is used if we first stepped into a function and now want to simply execute to the end of that function and step back up to the calling context.