An Examination of the Private, Personal, and Public

I was planning an essay to post on here, about someone from a previous employer who really was formative in my personal growth and professional development over the last 7 years. But, I struggled to finish the essay. Actually, I couldn’t really write more than just sentence outlines.

This left me puzzled. I wondered what could be holding me back. After some digging, I realized that I was holding back because I needed to share some private details in order to provide context to the extent of the impact of this person on me. I considered sharing these private details. What could go wrong? This is how it is now, I’m just sharing and this is acceptable now on social media, even on LinkedIn.

I decided against sharing these details and posting the essay on LinkedIn. A couple of ideas emerged as the main reasons why.

The first one was that I didn’t want to set the precedent for myself that sharing private details is part of my activity on LinkedIn. I don’t believe in constructing a work-friendly persona of myself. Ain’t nobody got time for dat! Anouk Pappers puts this in these terms:

“On the other side of this dichotomy, people usually use “professional” presence to refer to a scrubbed, work-approved persona. But this too is not realistic. We shouldn’t present ourselves as someone we are not, or even express inauthentic views, just to fit into a particular work culture. I think it is becoming increasingly important that we be our authentic selves online and that we position ourselves in a genuine manner. In essence, we need to establish and maintain an online presence across all of our accounts that accurately reflects who we are and how we want to be perceived.”

Rather, I didn’t want to turn my vulnerability into a currency, that I trade with, with hopes that the trading brings in ‘income’ later. I remember reading a Facebook post (in Arabic) a few months ago about a TikTok vlogger who had converted his overweight state into videos that brought in money for me. The post lamented that this is all it was now for him, to eat and show off his physique on TikTok. I thought further of another TikTok vlogger, who has become his signature dance – a dance and then showing off his afro. Is that all that they are now – their ‘products’? I am nowhere near their reach or fame, but I am close to them in that I could easily transform my inner life into some form of product.

The second reason was that I reflected on the differences between private and public information. I remembered a conversation I had years ago with a journalist in Sweden, who taught me the distinction between public, personal, and private information. From his training, he was taught that private is like the contents of your journal, stuff that’s for your eyes only. Others may not understand the context or importance. Personal information is where you can write about your experiences, but in a way that resonates with others. Think of you talking to friends about your experiences, showing them that they can relate. That’s personal. Public – news, commercial and legal texts. No emotion. “Just straight facts,” in my friend’s words.

Given this model, what I wanted to share in the essay is private information. I would extend his definition of private to include those also in my inner circle. Personal is what I’m prepared to share with friends and perhaps some at work, while public is whatever I post online.

The line between private and personal has been blurry for me for a while. I have written vulnerable essays on Facebook that I have set to public. Was that really a sound thing to do? The answer to that question didn’t strike me with much confidence. I wouldn’t say that I regret posting those essays, but now there may be archived pages on the Wayback Machine. 

The food for thought for all of us is, what are you prepared to have the Machine index? 

George Couros puts it in another jaunty way, quoting Seth Godin:

“Everything you do now ends up in your permanent record. The best plan is to overload Google with a long tail of good stuff and to always act as if you’re on Candid Camera, because you are.”

This pithy quote gets to the heart of my objection, that I don’t want everything on my permanent record.

The final reason was that there was no way to write the essay without these private details. Leaving them out would make the essay cryptic, and then there’s the danger of cryptic-posting in order to get people asking for more in the comments. Or, writing around the details would make the essay harder to understand. Then, what is the point of even posting it?

I found this quadrant diagram, while doing the thinking for this post. It takes the models, put forward by George Couros and Anouk Pappers, cited above to a further level.

When I analyzed my essay idea, the core idea – the guy whom I wanted to celebrate – was in the green quadrant. But the meat of the essay lied in the red square, and I struggled to argue to move it to the yellow square.

Thinking holistically – that is, engaging my emotions while activating reason – is helpful in evaluating what I put on the public record.

#ProfessionalDevelopment #CareerAdvice

The Curse of Over-engineering

We have two half days (affectionately known as Freaky Fridays) at work a month, where we get to work on our own projects or explore something new. Yesterday was dedicated to exploring Angular 2.

I thought that it might be a good opportunity to test it out in a real-world application – my Flashcards app to help me learn Swedish vocabulary.

The syntax isn’t too dissimilar from AngularJS, but rather is abstracted in more boilerplate code. Getting a basic app going, by following the Quickstart Guide, wasn’t too difficult.

“Look at where you have to be.”

Then, there was a knock at the door. It was Earl, the Grim Reaper of Over-Engineering. He asked me to remember that I am a software engineer and that everything has to be TIP TOP from build one.

So, the curse kicked in and I started scrambling to get the basic setup working with Webpack. I tried cramming in a Webpack tutorial, alongside the Angular 2 tutorial. Soon, it just became about cursing the day Webpack was built and racing through Stackoverflow, hoping someone else wrote something to make everything PERFECT now.

10 minutes before the end of the day, I realized… wait.

The goal was to learn Angular 2 and use it to build an app.

That’s it.

I told Earl that there was another engineer across the street, about to do something simple. He scurried away.

I gutted out the Webpack configuration and stuck with the lite-server package suggested in the Quickstart guide.

Moral of the story: fuck Earl and fuck over-engineering.

 

Learning How to Work in a Team

I am working on a new feature for one of our microservices. It’s about a medium-sized T-shirt that involves working with AngularJS’s ui-router, working with new API endpoints, and writing some CSS from scratch. I’m excited! And a little daunted…

To work against being overwhelmed and becoming unproductive, I focused on tackling the hardest part first – the routing and views. I knew that I was going to work with ui-router, so I read through a few tutorials and brushed up on routing in AngularJS.

I then put together quickly some mock views to connect to the new states and routes. This felt better than starting to code markup and styling, I had to remove the unknown first.

The tutorials only got me so far, so I stopped and thought about it. I did some searches on Google. After a few iterations on this cycle, I reached out to a coworker. Instead of telling him it’s broke give me the codes!, I explained what I had done, what I was trying to achieve, and what wasn’t happening as I expected. Rather than him coming to help me google, it turned into a discussion about patterns, structuring code, and a brief pair-programming to get something working quickly. I even got some praise that my initial concept is good and that I should just find the right balance, between sound design and time spent on the solution.

I thought of this article after the whole discussion with my coworker.

Addressing GitHub’s Vulnerability Warning in Your Code Repository

If you’re not averse through trawling through threads on GitHub issues, this is a concise list on how to address GitHub’s vulnerability warnings in your code repository. You will see a yellow-coloured warning box if one has been detected in your package-lock.json file.

(Courtesy of GitHub)

Assuming that the offending package is hoek:

  1. $ npm ls hoek
  2. Examine the output.
  3. Look at the package listed at the top of the tree – json-serverin this case. Hoek is a subdependency to it via request, so the latest (or, updated) version of request would solve this issue.
  4. I looked at the releases page for json-server and updated my package.json`to the latest version of the package.
  5. $ npm install
  6. If you run the first command again, you either will see the updated version of hoek or it won’t show up at all. The latter case means that it was dropped in the latest version of json-server.

There you go! May it save someone hours of pain and Googling…

The Weekend It Was – Midsummer, Code, and The Lake

I’ll write about the whole weekend in one single post because I now have two new email subscribers! Thank you, it means a lot…

This weekend was about staying in the discomfort and coming out the other side.

Coding

WordPress Development

And the other side is really sublime, calm, and beautiful. I had been procrastinating on a large coding project for a while now. It was scary and seemed insurmountable. I did a little bit every now and then, but I thought that I could get it done in one major marathon-session. That never happened.

So, this weekend over two sessions, I got the project done. It’s for a WordPress theme and plugin for a non-profit organization, so that their members across the world can set up a new website with information pre-populated from a centralized store.

It was good to be writing PHP again. The plugin and theme architectures take a while to get used to, but I’m impressed by what I can do with the API.

Custom PHP Application

Last year, I started coding a basic web application so that people at my church can digitalize the readings used in our liturgical services.  A few weeks ago, the main user told me that he needs the link to the app. So, as I was about to re-send him the link, I discovered that there were some bugs in the app. (Read: the app didn’t work.)

I understand fully now why we have code reviews, pull requests, and documentation. The code made absolutely no sense to me. It could only speak to my state of mind (frazzled) last year.

An opportune time to bring in unit testing, I went straight to where the main bug was and see how I could fix it. It got messy. I installed and configured to use PHPUnit with phpunit-watcher. The lion share of my time was getting the unit tests to reference the code and play nicely with Composer’s autoloading.

When it finally did work.. I realized that this function was doing too much. Writing the unit test compelled to refactor it to this. It still needs more work, but the process taught me a lot.

Midsummer in Sweden

It was a delightful and beautiful time, watching the raising of the Midsummer pole and families dancing around.

20180616_1504008436154387916906822-1

Picture 1 of 21

… took some videos, too

 

 

A first day with test-driven development

This is a little late, but better late than giving up.

Yesterday was hard. I spent the whole day, trying to get a testing stack going with Mocha, Chai, and AngularJS. It didn’t work, so I switched to Karma, Chai, and AngularJS. It kinda worked, but not entirely. So I switched to Jasmine. Still no cigar.

It was frustrating and a little demoralizing. But, I’ll try again on Monday.

Inching Towards Test-Driven Development (TDD)

The most striking part about MPJ’s series on unit testing is his biting and hilarious incarnating and characterization of the three most familiar voices in many developer’s minds: the anxious, the judge, and the over-engineer. Just watch one of the videos. Those names are my own, by the way. (Challenge: figure out which voice is which name I’ve given it!). Developing this further, I like to call them the Office of Sabotage. I actually thought of Amanda Palmer’s “fraud police” as I watched MPJ’s video for the first time.

I really could engage with the anxious voice today as I hunkered down to write some tests for a feature I’m pretty much done with. Yeah, I know, real TDD would have entailed to do it first! Baby steps, bro…

It wasn’t easy and felt clumsy as I tried to write the first suite. I wanted to start out with writing the tests straight in the testrunner (I’m starting out with mocha right now), but I had no idea how to start. Watching someone code doesn’t always translate to doing it myself. So, I took a step back and started thinking about the test cases by writing them in the same JavaScript file I wanted to test.

This became easier. I could see the code I was testing and it made it easier to work backwards.

Context: I’m writing tests for a feature that sends text messages using our internal system. There are three components:

  • the front end controller
  • the front end factory that calls the API controller
  • and, the API controller that consumes the back-end endpoint

As I ignored the Office of Sabotage’s attempts to… erm… sabotage me, a couple things occurred to me:

  1. We just assume that the API controller will always receive the POST parameters, there are no checks at all. Something I should cater for in a test…
  2. The error handling is a little clunky and not harmonized. It almost feels too brittle. Something to be dealt with in a test and maybe reworked in the refactor!

Today was just day 1. Tomorrow was a new day. When I got stuck, I fired up the video and just coded along.

Will report back (and write more about TDD)!

 

Approaching Documentation

One of my goals at work for the past month has teen driving efforts to improve our internal documentation for front-end developers. It would have been easier undoubtedly to just rant about it at meetings and talk about grandiose projects. I chose rather to do something about it in my own work.

  1. Pull requests. I used to just put a descriptive title and leave the description empty, sometimes linking to the original issue. A call-to-action came from my coworker, who asked me for a brief summary of changes so that it’s easier for him to understand what he was about to review. So, I put in some screen shots of any UI/UX changes, a few lines about background, something about the context for the pull request, and finally a short list of the main changes. In the last couple of weeks, I’ve started also adding links to any relevant documentation I wrote, such as backend API endpoints or anything in our product wiki.
  2. Internal documentation. We use a popular open-source system to house our internal front-end documentation. So, I’ve made it a part of my workflow to document any backend API endpoints in our system. That way, some developer won’t curse my name and the day I discovered programming when they have to maintain or debug my code.
  3. How-tos and repo documentation. Taking my coworker’s request further, I expanded any developer documentation that lives in the repository. This is usually either how to get started or how to implement a new feature. The effort spent on this (and README.md in tow) will hopefully mean that other developers will find it easier to get going with the codebase.

I actually like writing documentation!

My Strained Relationship with Software Development

I wrote the original version of this piece, last year on Medium. This is an expanded and less guarded take.

I didn’t want to study software engineering in college. I first wanted to study English literature and drama. That wasn’t an option at home. So, I looked at the other things I had dreamed about since childhood – architecture. I put together a portfolio and applied to Bartlett School of Architecture in London. They hid the rejection letter from me and told me no. So, I fought them and the first compromise was computer-aided product design. I just wanted some art in whatever I studied.

There was none of that. It was all math, physics, and science.

Continue reading My Strained Relationship with Software Development

JavaScript on the Command-line, a tiny repo

Over the last couple of weeks, I have been working on a project to make Kivra’s web app ready for other languages than Swedish. It’s been a great deal of manual work, going through the codebase and moving strings to our copy repository.

This involved a lot of cross-checking and checking that the strings are being used or not. After a little while of using find/replace in Atom, I realized that this was going to take a long time.

So, I put together a little gist. That gist turned into a simple repo that I whipped together.

After customizing the repo with some tooling and npm options, it seemed like a good idea to generalize this into a boilerplate that I can reuse for other support systems or for my own projects.

Hip names, congruent with 2018 tech, escaped me, so I went with the obvious: JavaScript on the Command-line