First Day at Work: Orienting Yourself by Matching Abstract Actions to Concrete Tools

On October 2024 I entered a Software Engineering position on a new job. This was one of the first things I jotted on the yellow spiral bound pad I brought along with me.

 

To orient myself, I made a sort of table with all the common stuff I do in my day-to-day, and what they're using in the new place as opposed to my former workplace.

Putting this data into a table, you would see something like this:

Action	Old Workplace	New Workplace
Messaging	Slack	Zoom
Video Meetings	Google Meet, sometimes Zoom	Zoom (even though Google Meet is available!)
Email	Gmail	Gmail
Documents	Google Docs	Microsoft Office over Dropbox
Wiki	Started with a self-hosted mediawiki (with a git backend!), eventually migrated to Notion.	Wiki built into Redmine
Tickets	Jira	Redmine + Trello
CI/CD	Proprietary solution on top of Jenkins, started moving to Argo CD around the time I left.	Jenkins
CVS	Started with a self-hosted GitLab, moved to GitHub.com .	SVN built into Redmine! I kid you NOT!

Tooling differences between workplaces reveal something.

On one hand, work can feel pretty much the same across workplaces. "Here I am, sending messages in a public Slack channel about my Python code... again!".

On the other hand, each place has its own way of doing things ("this is how we do it here").

Bad places stick to titles: "We are practicing Agile and work in Sprints."

Good places keep the Abstract and Concrete separate: "Here is how we do Agile here - perhaps differently from how you did it in your previous place; you know how it is...."

Moreover, tools are not interchangeable, and you need to learn the differences in order to become effective.

An obvious example is SVN vs. git: if you're used to one of them, switching to the other is going to be annyoing.

A less obvious example is Zoom vs. Slack; I did not imagine Zoom will be missing so many basic features, such as inline code in a message's body (`foo` automatically becoming foo was only added on the December 16, 2024 release).

Sometimes an available feature isn't used. My team used to write Markdown documents rendered to HTML with **asteriks for headlines**. Using ## hashes for headlines prompts the rendering to include an anchor, making it easier to post a link to a specific section of the document. Slowly but surely, by setting an example rather than forcing it, I'm making the usage of headers more common.

For fun and profit, one should:

• Identify the abstract Actions you would like to perform, drilled-down as deep (or shallow) as you choose:
• "I want to work with git, and nothing but git."
• "I want my messaging platform to support code blocks."
• "I want my automatic anchor rendering for my documents' headlines."
• Identify which of these Actions can be concretely performed by the tools available in the organization right now...
• ...and try to close or at least note the gaps, ideally bringing in the new tools if possible (considering licensing, budget, security, legal, etc.).
• It goes both ways, of course: identifying the actions the organization is routinely performing, finding or generating an official description for them and learning them is one of your major goals as a team member.

Sometimes the organization itself isn't too worried about everyone being on the same page about what's being done. And that, I believe, is where trouble slowly but surely enter your work-life.