I used to be notorious at pirating software in high school and university. I even became friends with a guy in university that reverse engineered application serial keys. He tried to teach me but that was too 1337 h4x0r for my brain, that being said when I graduated and started earning a paycheck I thought it was hypocritical of me to sell my services as a software developer and expect people to pay me but I refused to pay for other peoples software skills. I felt that if there was a time God would pick me out specifically for some punishment that would probably be it 😅. So I started buying/paying for software. The software we decide to pay for is a good indicator of value we feel they bring. Inspired by Pat Walls's post I decided to write down apps I pay for and use for work as a developer. I love reading these lists because I usually find one or two gems that I have never heard about that changes my workflow for the better. I hope I can do that for someone.

Spotify

Software development would be a different process for me if I do not have music playing.

Digital Ocean / Linode

Honestly, I have been meaning to migrate all my sites from Linode to Digital Ocean but I have not had the time or maybe I am just scared that I will break some of the ancient code and scripts that I am happily running on my Linode box. Regardless, both are great I just find Digital Ocean to be more modern in its offerings and I'm a sucker for good branding.

Sketch App

This is the first app I learned to design on, I never understood layers and the way Photoshop and other Adobe apps were laid out until I used this app. It has become a major part of my arsenal. I cannot remember an app I have worked on in recent years that did not start here

Affinity Publisher

A fantastic replacement for Adobe InDesign. Sometimes I design brochures, marketing assets and proposals for my company. I just bought this recently but I like what I see so far.

Affinity Photo

If Photoshop is too expensive this is the way to go. It handles both illustrator and photoshop files and is equally as powerful, at least for my uses. I cannot recommend this enough. One time payment as opposed to chokehold subscription of Adobe suite

Apple Developer account

I make apps that I want in the app store so I have to pay the beast its dues 😅.

Adobe illustrator

I am on the verge of dumping this for Affinity Designer. Great app though.

Pixelmator Pro

Good replacement for Photoshop on a mac when dealing with images. I prefer Affinity photo because it has a wider versatility with file formats and you can do more, but if you deal mainly with photos and no SVGs, PNGs, etc. This is cool.

Gsuite

For my blueportsoftware.com email address

Google One

Cloud storage with cheaper tiers than dropbox. I do not currently need more than 100GB of anything in the cloud, Google already owns half of my life... why not give them more of it 😅

Tunnel Bear

Ok VPN, to be honest, Nord VPN is probably better, but they caught me on branding and then they charge me yearly and they renew without notice and I keep promising myself next year will be the year I cancel my subscription on time.

Microsoft 360

Microsoft Word, Powerpoint and stuff

Postmark

Transactional email, I have used them for about 10 years now. I love the company philosophy, love the application. I am never leaving.

Twilio

Programmable SMS. if you are in Nigeria you can use Africa is talking as a good alternative also cheaper, if you have international clients, use Twilio.

Istat Pro

I don't work specifically with this app but I use it every day, gives me insights into all the hidden parts of my computer. How much work my CPU is doing, how much I am downloading or uploading at any time, what apps are draining my resources etc. I install it on every Mac I have ever owned since I can remember.

From time to time I have talked potential clients out of doing business with me and my company, not because I did not think the job was great or I did not want the money. It was usually because I knew the project will ultimately fail. The project would fail because they were not financially or mentally ready to maintain the kind of software they were asking for. I could easily take the money, build what they wanted and stopped when they ran out of money but they would quickly realize that they need more work than they anticipated and then feel like they have been suckered into a scheme. This leads to a bad customer experience and a bad reputation for my company.

There is this huge misunderstanding with most clients and it is that there comes a time when the software will be COMPLETED and in most peoples minds this is the time where the software does everything they envisioned it to do, it has no bugs, all their staff are fully trained in it and they will not need any changes to it in the short term, but this is rarely true. I call this the "Happily ever after lie". You see this fallacy in life also. As children we were told, if we got good grades in school we would grow up to live happily ever after. When we got good grades we were told if we got this one good job all would be well. When we got the job, we were told if we just got married we would be very happy and when we got married we are told we will be finally fulfilled when we have children. I can go on and on but you get the picture, the goal post is always moving. Whenever I want to agitate my dad a little, I tell him he has lied to me my whole life about life😅.... but I digress.

This lie also exists in software, the goal post will always move. This is because Software is a tool and not a business. As your business grows, your tools need to adjust to fit your business needs. A baker who makes 3 cakes a day from his or her home kitchen cannot continue with the same process when they grow to 100 orders a day. Their tools have to change. Understanding this will allow you to scope out solutions to account for some growth but you cannot foresee all the future changes, this is rarely communicated by developers and is widely unrecognized when budgeting for a project. This is unfortunate because it comes as a huge shock at the end of the project when every feature that you asked for is completed, it works exactly as you imagined and very quickly you start to see things that need adjustments. This issue is why I give clients a 3-month warranty from when I deliver the software to make little tweaks and bug fixes at no expense to reduce the blow and the realization.

"Like Art, Software is never finished only abandoned"

I once read a quote somewhere that said "Like Art, Software is never finished only abandoned" and I could not agree more. As a tool, we need it to grow with us and as it is left in the open, people interact with it in many different ways we could not anticipate so we need to patch these issues as they are found. Understanding this and communicating this to clients has really helped in bridging the gap in what it takes to create and maintain a software system and advising organizations on a realistic budget on their software needs.

-Happy New Year! 🎉

I used to be terrified of reading large books. I am not sure what it was exactly but I was already defeated by just looking at the thickness of the book. This was of no help since my Christmas money was tied to how many books I read that year. Every week I picked up a fictional book, read it and wrote a summary for my mother, if you didn't finish this book by the end of the week it carried over to the next week, so the smaller the book the better 😅. Still every year my younger sister beat me.

I remember the first day I saw a Harry Potter book (Sorcerer's Stone). A friend of mine had it on her desk. It was not a particularly thick book, but thick enough. I read the back and then the inner sleeve and before I knew it I had read the first three chapters. I was hooked. I finished the book 1,2 and then 3. The fourth book, The Goblet of Fire was released just as I finished book three and that shit was huge. That was by far the largest book I had ever tried to read, It was daunting but I was on a mission. I soldiered through and crushed the book. When I finished it, it was like a part of my brain unlocked and I suddenly wasn't afraid of big books anymore, I suddenly could not remember why I was afraid to pick up thick books, the fear just vanished and a whole library of fiction became accessible to me and suddenly I could not stop reading books.

A lot of people always ask me. What is the best way to learn programming? The one advice I give everyone is: Find your Voldermort. For those not familiar with the Harry Potter series, Voldermort is the big bad guy in the books, if you are video game person, he is the final Boss. I found that this phenomenon (Unlocking my mind to possibilities) happened to me whenever I took on a large enough or complex project with lots of unknowns. I experienced this the second time when I completed a Social Network I created in University called Igbadun. Suddenly every project I built afterward became a subset of Igbadun. Igbadun was a social network built without any frameworks so everything was written from scratch with no libraries. I always tell people the reason I wrote it all from scratch was because there were no frameworks in 2005 which is partly correct but the truth is I didn't even know better🤦. My friend and I wrote our authentication system, database connections, and wrappers, painstakingly wrote every query in SQL, designed our emojis, built a user permissions and moderation system , etc... my head just hurts thinking of all the stuff we made that is one line of code today. It was buggy as hell, the site crawled to a halt if we had more than 100 people on it at once and honestly it was a shit show of unmaintainable code, but at the time it represented so much hope. We had something that was working, that we used and our friends loved that "rivaled"😂 Facebook and Hi5 in our minds 🙄. I can say single-handedly that defeating that Voldermort gave me the confidence and inspiration to pursue a career in software development.

When I pick up a new technology now, I find a big bad Boss Project to bang up against. It always sucks. You can find me swearing at my computer or on my knees asking for divine intervention but as long as I complete the project I am flooded with a world of inspiration and ideas. It happened when I took on a project at work that lets you slice and dice videos by interacting with its text transcript. It happened again while building a ride-sharing app for Android and iOS. I have found giving myself a challenging worthwhile mission, which forces me to study the fundamentals of what I am trying to solve is the best way to open my mind to see all the opportunities that knowledge brings with it.

One day during one of our office lunch breaks, Ben and I walked quietly across the shopping mall where our office was located to find some food. Ben turned to me and said "...You know I have a Thankless Job". Ben had just been reprimanded by the CTO (Chief Technology Officer) for a bug in the company's video player for what felt like the millionth time now. This was my first time hearing such a term and I asked him what he meant by that. He explained that if he did his job perfectly no one would know any work had been done at all but if he messed up just a little there would be a shit storm... in his words "There was no glory to be had".

To give you some context. It was 2010 Google Chrome was 2 years old, Internet Explorer had 50% market share, Twitter Bootstrap did not exist and the largest open source community on the internet was sourceforge.net 😂. It was also the time that if you wanted to watch video on the internet you had to download Adobe Flash virus Player. There was no HTML5, there were no video tags.

My first job after university was at a startup that did qualitative market research through video. We sent webcams to your house (because in 2010 barely any computers came with cameras) and whatever product we needed you to give feedback on we would send it to you also, then we paid you after you finished reviewing the product. Sometimes we needed you to review something as small as toothpaste and sometimes it was as big as a car, payments ranged from $50 per review to hundreds of dollars depending on the budget of our client. Your review gets uploaded to the system, transcripts get generated and our researchers' slice and dice the video to find key insights for our clients. It was focus groups digitized. To get such a system up and running at the time, we created a lot of proprietary technology and one of them was a Flash video player which was at the center of the whole system. Ben's job at the time was re-factoring the video player. If he did his job perfectly, no one would be the wiser but any tiny mistake was the loss of confidence from our clients, the project management team and the executives of the company. It is a hard position to be in.

The idea of Thankless Jobs haunted me for several years, it just didn't sit right. This is not unique to software development, Thankless Jobs are everywhere. You see them when we go to the stadium to watch a sports game, and you have no idea how many thieves or terrorists the officer you just walked past apprehended while you ate your hotdogs and drank your coke. You see them everytime you use a public bathroom and you have no idea the mess the Janitor cleaned up before you walked in etc. To attain self-actualization we have to feel we are positively contributing to society and that the society recognizes this. Most of us do this via our day jobs, the fact that there are jobs in which no one can visualize or perceive your contribution until something went wrong worried me. It is because of this very issue I added processes like Build software in the open and wrote a post on Communication. Not because I needed the thanks, but it made clients aware of the actual value they were getting, which made them happy and which in turn allowed me and my team to self-actualize.

This came full circle for me recently when I learned about the Service Recovery Paradox, which is when someone places more trust in a system that recovers quickly after being notified of an issue, rather than a system that silently succeeds all the time. Trust and Gratitude come from the observability of a process and Thankless Jobs are jobs where those in charge or those being served have no visibility into what it takes to execute in that job. This is why reports are important to managers, this is why status updates are important to clients...visibility. It moves your position from being suspicious to one of being open, transparent and collaborative. So if you ever find yourself in a Thankless Job, where there is no glory to be had, increase the visibility of your process. Send daily reports or have weekly status meetings. Do not work in the dark.

UPDATE 22 October 2019
Ben and I built ShipScoop to increase the observability of and visibility of your process to your client's and managers. Take it for a spin.
https://www.shipscoop.com/

• Thanks to Ben Roux and Uzo Olisemeka for reading drafts of this.

A couple weeks ago I read a sad tweet from @theshalvah

There is a lot to unpack in this discussion and many topics we can address but I wanted to talk about the last part... tech and give a deeper explanation to what I was trying to say.

In the tweet above I said, "...tech is the 'easy' part" it seemed to rub @efe_ariaroo the wrong way which is totally understandable. I put Easy in quotes because I am fully aware that solving programming and technology problems are VERY hard, some problems take days, weeks and even years to solve by huge teams and sometimes nothing still works, that being said, in the context of business, tech is the easy part. Let me land. 😅

There was a rude awakening I got when I started Blueport. Tech business is like every other type of business there ever was but in the tech ecosystem, there is a lot of "evidence" that tries to coax you to think otherwise. The primary purpose of any business is to create profit... that's it! We, humans, have found that the most sustainable type of businesses are the ones that create real value to a customer and we the business try to capture some of that value for ourselves and that is what we call profit and we repeat the process... till we die or the business no longer is able to capture value for various possible reasons. If you are selling toilet paper, providing search engine results or trying to colonize Mars, this is the same formula every business follows to be sustainable.

Tech is reproducible, business success is not.

Now the reason I say tech is "easy" is that it is reproducible. If someone at Twitter writes an in-depth tutorial on how to create twitter (The software), any competent developer(s) will be able to reproduce twitter to the T (pun intended 😂). This simple fact is what makes tech "easy" is that it is science, it is reproducible, once it has been invented the knowledge can be shared on how to keep making it. What isn't reproducible is Twitter inc. No one at Twitter can give me a detailed tutorial on how to become Twitter (The company), that is not reproducible by any known formula. A simple practical illustration for this is the company Ghost. The company that makes the blogging software I use for this blog. Last week they announced that they are generating $100K monthly recurring revenue but this software is open source, they give it away for free and how they make money is by hosting blogs for others who do not have the technical chops to host the free software or do not want to be bothered. A naive person would think that because Ghost is open source if they start a hosting business tomorrow for Ghost, They are walking into a $1.2 million dollar business, but we all know that's not how business works and it is an oversimplification of the terrain.

It is also tempting to think that breakthrough technology will sell itself and this is where most people that dissagree with me point to, surely creating things that do not exist is the hardest part of running a tech business. Lets look at an example, a Teleporting machine, the ability to stand at one end of a portal and be transported instantaneously to another end. Surely after you create such a technology you will be an instant millionaire and your company will be immortalized forever. It will solve logistical issues such as international same day delivery for all sorts of complex items, it will simplify inter planetary transportation, asteroid mining etc. Once invented it would reign supreme. Here are a few issues I can see a company tackling after this is invented:

• Is this even real? Prove it.
• Prove it is the same human with the same conciousness and molecules that comes out of the other side and not an altered version.
• Does this cause cancer?
• How do we prevent the bad guys from using this?
• Is building this cost effective?
• Protests from the millions of jobs they are about to destroy.
• Who has the rights to such a powerful machine?
• If something goes wrong during teleportation who is responsible?

I can go on and on, but you get the idea. You need eloquent scientists, marketers, lawyers and a slew of other expertises to ensure the company is not destroyed by it's own success. If you don't believe me look up companies who are inventing the future like Tesla and the battles they have to fight to stay alive, and have nothing to do with the tech.

Although tech is the most significant part, in most companies it is not the hardest part of keeping the company alive, there is so much more to running a business than the solution you are providing, the way you communicate the solution is important, the way you deliver the solution is important, the machinery behind the scenes that maintains and improves the solution is even more important, all these steps involve humans and touch points with humans and humans are unpredictable hence why there is no one book that is the manual to business success, you cannot tutorial your way to success, but you can tutorial your way to creating a Shopify app, an Instagram clone, you can even tutorial your way to creating an app that has never been invented before from mashing several tutorials.

This is the motivation for my reply above. If you are running a business and are paranoid someone is gonna steal your tech, then your business has several underlying issues that are not tech related that you need to fix. Unless the person that stole your tech has the capability to deliver it better than you can, and communicate its ability to customers better than you can, they cannot beat you at your own game, if they can, then that is on you, not them. The point I'm trying to make here is that from my experiences, I see lots of clients who think once they have the perfect tech, everything is cruise control. What I am saying is No, tech is the easy part, If done well it is reliable, but the rest is not. Get that out of the way as soon as you can, you have lots of other battles to fight ahead of you.

It is the holiday season and most of us are on holiday. At home visiting family, going to Christmas and house parties. It is the end of the year where we review the past year, decide what we liked about it and make new years resolutions around the things we want to change about the past year. One of the things ending for me is the creation of these playlists (Work Station). It was a fun experiment that I wanted to share some of the music I listen to with all of you, give you a glimpse into other parts of me as a human and I feel that has run its course. From time to time I may still share an album or some tracks but this will be the last playlist of its kind.

As that cheesy Dr.Seuss line goes:

"Don't cry because it is over, Smile because it happened"

On that note, I'm closing it out with a party playlist.

⚠️ THIS IS NOT CODING MUSIC!

In 1982 Walter Doherty and Ahrvind Thadani published, in the IBM Systems Journal, a research paper that set the requirement for computer response time to be 400 milliseconds, not 2,000 (2 seconds) which had been the previous standard. It was found that when a human being’s command was executed and returned an answer In under 400 milliseconds, it was deemed to exceed the Doherty threshold, and use of such applications were deemed to be fast and “addicting” to users.

I see this all the time when I create applications for clients. The speed at which they get a response from a button click or tapping on the navigation affects the way they perceive the application. Kayak was famous for slowing down the loading of the screens that displayed your flight results to give the effect that the application was "thinking" or working hard to get you the best results and Instagram got praise for images seeming to upload insanely fast because they were uploading the images in the background while you typed the caption and chose the geolocation. Pretending that your user interface is faster or slower than it actually is, is a well-worn trick for creating great user experiences.

What I discovered recently is that this phenomenon is not just bound to technology. I found this is also part of human interaction. I have seen this from two angles. I find contracts I get that are larger than a month long, there has to be constant feedback with the client. This I discovered a while ago, what I found interesting recently is that it also goes the other way around. If I am dealing with a client that absorbs all the status reports but gives no feedback, the motivation of the project wanes. I have thought about this a lot recently and what the adequate threshold is. I found in any vibrant productive project, there is a solid flow of back and forth between the team executing a project and the decision maker. This could be the manager within a company, the CEO or a client of a consultancy, basically a feedback loop of what is getting done and how well it is getting done. I have made this mistake also with developers who what worked for me. In the beginning, they send me reports, I get excited, there is a flurry of communication and after a while, I just scan the reports because I trust them now and I know they are progressing, but ALWAYS I see they lose interest in the project and suddenly all the work turns to shit.

Living in Nigeria it is always easy to blame the work ethic or culture of the people but it was not until recently that I discovered that I was depriving them of something essential... Meaning. If you look around to most hard working people you know, almost all of them want to work on something that is impactful, something that affects other people. When they do work and they get no feedback, it feels like all the work is going into a black hole, it feels like all the work is in vain. I found a client is comfortable and feels like work is getting done on a big project if they get a weekly or BiWeekly update, I find the executing team feels like adequate feedback is given between a day or week from their update, anything above this and people start to drift. The other extreme of this is micromanaging the team and that also is not the answer... similar to the Dorothy Threshold the answer is in a range.

Traveling this year I realized that Afrobeat, A genre of music most Nigerian and West African jams fall under is getting popular internationally, being played more and more in mainstream settings ever since big groups such as Major Lazer have released hits in collaboration with a slew of African artists in the last year. Nowadays you can hear an Afrobeat track in a wide range of places. From Nightclubs in Addis to coffee shops in Berlin or a Nike store in Budapest. So this week it is a playlist of my most recent favorite African sounding songs from various artists.

A month ago I saw this tweet from @theshalvah

So, guess what? I asked them for feedback, and it was a rejection. Thankfully, they provided some feedback. But what pains me is that a third of it is plain wrong, as though they didn't look at my code at all. https://t.co/HJYmEuqMPA

— Thor, God of Static Electricity (@theshalvah) September 17, 2018

I immediately resonated with his pain and any programmer that has taken home an interview coding "assignment" or done pair programming in an interview can also relate. I encourage you to read the conversation that evolved out of that tweet but the short of it is that the interview process for developers is broken and there is a disconnect between what interview candidates think is required from them and what the employer is looking for. This will not be a post about how to fix the developer interview or how to prepare for an interview but an expansion on my reply to @theshalvah and hopefully help others get in the right mindset when doing coding interviews.

My dad once told me that while employing someone there are only three things you should look for:

1. They have a happy positive attitude towards life and your company
2. They are humble/obedient
3. They like to learn

At first glance, this looks like nothing. I first heard this as an employee but now that I hire people, it is a very insightful summary that captures what a good or smart employer is trying to capture in an interview and I'm stating it here to put some context around the advice below.

Ask A LOT of questions

I learned this trick from a friend while preparing for interviews in university. When an assignment is given to a developer, it is instinctive for your mind to start working. You start making assumptions and taking initiative, which is good, developers are creative minds and that's how it should work, but at this moment it is best for you to pause, slow down and drain EVERY answer you can get from your interviewer. For example, let's say they tell you to build a forum. It is easy to jump and start working, cause we all know what a forum is, we have all used one and we have even made some, so its an easy project... NO, this is a trap. Ask mundane questions like:

1. Who will use this forum?
2. How should it be branded?
3. Do they need accounts?
4. How often does the average user return?
5. Should their session be persistent or do they log-in every time?
6. Does this forum have multiple topics or just one?
7. Do you allow unregistered users to read / post on the forum?
8. Is there a moderation system?
9. How do moderators invite other moderators?
10. etc. etc. etc.

Some of the questions above are silly and in the context of an "assignment" it does not even matter but it is important for you to approach the problem as you have never heard of a forum before. It is tempting to show "initiative" and suggest the best implementations of a forum you have seen or thought about but that triggers the wrong flags for the employer. What the employer sees is someone who thinks he/she knows everything, has their own ideas about how their assignment should be done (Basically telling your teacher how your assignment should be marked) and what is even worse is if you get into a debate with the employer on the best implementation of the assignment... but more on this later.

Asking questions is the best way to show initiative. By asking questions you signal to the interviewer that you are thinking, you are humble and making no assumptions about the assignment, it also signals you are obedient cause you are asking for direction. When it starts to sing is when you ask questions that the interviewer has never asked himself/herself yet, that signals initiative to the interviewer, they are like hmmm, I like the way this guy is thinking and then you both collaborate to find out the answer together and suddenly the interviewer gets a glimpse of what it is like working with you as a team member. It is very refreshing. This strategy also eliminates the gotchas interviewers usually put in their interviews to throw you off base. While asking "silly" questions, the interviewer will be forced to divulge that the forum is for blind people. Something he was gonna toss out at the end when you thought you had conceived the best forum ever. Another good effect of asking questions is when you can suggest features based on the new information you have. For example, you find out the forum is for blind people so you can suggest if they can make posts by talking to the computer instead of typing or if it will have text to speech. You cannot make these suggestions if you took forum at face value.

The developer has to remember that the company started without them and will continue to operate without their wisdom (if they are not hired), because when they go out to look for someone to hire, they are rarely looking for someone to "Save Us" but someone to do what they need to be done, having your own relevant ideas is a bonus to them, not a requirement. So someone who assumes he gets everything about their company from an hour interview is irritating at best. Asking the dumbest questions till you cannot think of anything else is the best single advice I can give when asked to build a system for an interview. It is a shame that this is not well communicated by interviewers when they are looking for candidates because as developers we are taught the opposite.

Concede when you disagree but be clear on your stance

While asking silly questions, you may find your potential employer making decisions that you think are terrible. It is natural as a developer to interject and explain to them why their decision to animate their web page with C++ is wrong, this is a mistake no matter how politely you say this. A better approach is to ask them why they decided to use this tool to execute this task, listen to their answer, ask them follow up questions if needed, truly try to understand what drove such a decision and then summarize what they told you back to them, for example "I understand you are using C++ to animate your web-page because it is an object-oriented language" and then proceed to tell them that you think Javascript can do the same for them and even more in detail and then ask them if this is something they have had a chance to look into, if they persist on C++, concede by saying "Ok, I understand your rationale." and move on. If they ask you to tell them about javascript... by all means blow their minds. This shows obedience on your side and a willingness to learn from them. Getting into a sparring match with them only signals how stubborn you are to them, which is counter-intuitive for a developer because we are in an ecosystem that is democratic. Technologies usually win based on merit, so it is in us to explain logically and factually why they need to re-evaluate their stance, although this is a good move when you have the job, it is not during an interview.

They want you to win

It is easy for a developer to feel that an interview is an obstacle course set up to trap them and embarrass them and make them feel less than, but it is quite the opposite. Developers have to realize that people who work at a company must have more important things to do than to ask strangers hard questions only to watch them fail and laugh about their answers in the company kitchen during lunch breaks. Every interviewer is secretly rooting for you to win. They want this whole process to be over almost as much as you do. It will be great if the very first person they interviewed was good enough for them to hire. Aligning your attitude to the fact that the interviewer is your friend, brings out the smiles in you, the calmness, the jokes and puts your nerves at ease to show your best self. Better than being on edge waiting for the next bomb to drop from the interviewer's mouth wondering if that is the one that will take you out. But why won't the developer be on edge when we call it a "coding challenge". This only gives the vibe to a developer that this is an attack in which they have to defend themselves... but I digress. Understanding that the interviewer wants the developer to win helps the developer ask the right questions and bring the best mindset to the table.

I will like to finish by saying an interview is like a date. The fact that you are there is because they are hoping for you to be "the one". You should also be aware that this is two-sided. You are selling your time and they are buying time. As much as companies like to keep the dynamic they are doing you a favor by hiring you, it is an illusion, they need you as much as you need them, so only take jobs that you are comfortable about the amount of your time they are buying.

Back in 2012 - 2014 I was addicted to gummy bears, Haribo to be specific. I ate one or two packs a day. Looking back at that time now my stomach just hurts at the amount of Haribo I put in myself. I was also getting nice, round and squishy just like those bears in the packets of Haribo I ate 😂.... but I digress.

During that period I had just gotten addicted to Electronic Music and it was like I found a new world. I went to every music festival I could find in North America, from Global Dance in Colorado to the Electric Daisy Carnival in Las Vegas... I was there. Addiction is a mysterious thing, I have been blessed to not have an addictive personality and if I ever found myself forming a habit that negatively impacted me I could easily eject myself. I never really understood the mind of an addict until I watched John Spencer explain his love for Scotch on the West Wing. Side note, West Wing is one of the greatest shows I have ever watched..just saying.

In the grand scheme of things, it was all "negligible" my friends will say when I confessed I was addicted to these things. People tend to downplay addictions if it is not hurting their lives or yours. A funny quote a friend would tell me when I questioned his deep love for poker. He said, "Adim you are only a gambling addict when you are losing when you are winning you are a Poker Pro". Which is funny and sad at the same time.

This week is a few of the songs from 2014 that I listened to on repeat and teleports me to a time in my past where I ate lots of Haribos and danced all night at music festivals.

P.S. I still eat Haribos and go to Music festivals just not every month 😆

A couple months ago my dad said something interesting to me. He said, "Adim you know, football is a game of forgiveness". He goes on to explain that in football a team works together to gain the ball, maneuver it through various obstacles and challenges and then passes it on to a striker to create a goal. At any point towards creating this goal, the ball could be shot out of bounds, or a player can lose the ball to the other team and the team quickly regroups to attempt to get the ball back and try it all over again. To do this the team has to overlook all the mistakes their teammates make in order not to break the team morale, they have to quickly forgive and forget and move forward in the game. I have never looked at football this way. I immediately had flashbacks to when I played soccer in secondary school. I remember when my team would hustle to get the ball, pass it meticulously and with the precision that will make any premiership team smile at us, only for the striker to take some careless shot or do some stupid dribble and lose the ball. I remember the pang of anger in my heart but I also remember how quickly we hissed and got back to chasing the ball again.

The story from my dad came to mind when I was talking to my friend Ben last week. His development team just finished creating a critical new version of their Dating website and app and he was congratulating them in a speech and in it, he said this:

"One thing I don't think people recognize is that engineers aren't really allowed to get down on themselves. When people get down on themselves, their work slows. They second-guess themselves, they don't work confidently, and they get less and less production. That means that when a website is at its worst, engineers need to be at their best.” ~Ben Roux

I resonated with this a lot because some days I get stuck on some code or running into errors deploying some code that I forgot to deploy first. I get so angry at myself for making a mistake I could have prevented or should know the answer but for some reason, it is still not working. I find myself spending time beating myself up and repeating the same steps over and over again like I am a madman, rather than stopping to think critically. When I catch myself in this loop, I quickly eject and forgive myself first, put myself in a good mood and then think through the problem again... but carefully. I find this simple step of changing my attitude to a forward-looking and positive one is the fastest way to think out of a problem.

Writing this I feel like I am writing about some pseudoscience, hand-wavy shit out of a self-help book, but this is not unique to Software Development. Any cerebral field, where problem-solving and strategy are critical to success. being a doctor, playing for a sports team, being an artist, an engineering and so on. To move forward when you make mistakes, you have to forgive yourself and your teammates, forget what happened and chart a path to move forward.

When I was a child around the age of 9-10, my parents bought me a magic set. It was a set of props and book with instructions that allowed me to perform some pretty awestriking tricks, accompanied with this set was a smaller book with 100+ tricks you can do with decks of cards and other household items. As you can imagine I went wild with this. I became the resident magician in the neighborhood and performed magic tricks for all my parent's guests and grandparents. This was all fun and games till some of my parent's friends called them aside to share their concern that allowing me to engage in this might be a gateway to me participating in witch-craft or even worse, some feared I was already a sorcerer 😂.

Like every nerd before me, my draw to magic was how being armed with a little slight of hand, psychology and uncommon scientific facts you could capture the attention of anyone and divert it to whatever and where ever you wanted.

This weeks playlist is focused on some interesting sounding tracks, that capture your attention because they make you feel like you are in space or in an ocean of emotion. That being said with your captured attention you are spellbound and focused deeply on your code and you get lost in your own head. Enjoy!

When I first landed in the US to start university. My dad and I hopped into a Taxi. I was excited, this was an amazing new chapter in my life. I was about to study computers... how is this even a thing? I imagined class would be like playing video games. Not in the terms that it will be relaxing, mindless and inconsequential but more in terms of it will be fun, an adventure and what I learn will give me new opportunities.

"Ah! you are going to RIT... that is a good school" the Taxi Driver said. It was a white man in his 50s with a scruffy white beard. "What are you studying?" he asked. "Computer Engineering," I replied proudly. "That's a shame.." he replied immediately. "Why?" I asked, at this point confused. "All the programming jobs are being shipped to India!". I remember thinking this man is bunkers, and what a rude thing to say to a new university student, but in retrospect, he was not wrong. For everyone who was not in the field, that was what was on the news. This was 2004 and the DOT com burst had just happened and then 911 caused a hit on the economy and so there was no faith in the expensive developers America was producing. India was cheaper (So we thought). I enrolled in my classes and quickly forgot all about that interaction. Luckily he was wrong, but why?

After graduating college, through a series of events I moved to Denver and worked in the same company with a College friend Ben. This was a startup and we deliberately chose this because we wanted to work in places where we could make an impact, where our code mattered. Many times the Chief Technical Officer (CTO) would come to us telling us about a new company initiative or instructions to build a new system and sometimes we would think it was the most stupid thing we ever heard. Ben was never shy about this, he would readily and easily show his disdain for the idea. I was usually more diplomatic but would express "concern". These disagreements usually turned into a respectful sparing match between the CTO and us, the CTO usually humored us but once in a while, when he had enough he would throw out his famous line "The decision has been made..." by whom? he never told us 😂. Ben was always the most vocal, I never told him this but I always wondered why he never got fired, actually I watched him get raise after raise and get promoted before anyone else. Now that I run a business, I know why.

The value Ben brought to the company was "Initiative". The ability to question if the steps taken by the company lead to the company's intended goal, his ability to work on issues he found before they were brought to his attention by his boss, and if the instructions he got were bad, he found other ways to achieve the same goals a different way. In small companies this is especially important, the leaders of these companies have to make decisions every single day, so a good hire for them is someone who can take the workload off their plate, a GREAT hire is someone who takes stuff off their plate and yet keeps them accountable for the company mission. Avoidable mistakes happen not when no one saw it, but when no one is bold enough to speak up to a bad idea or are too lazy to notice. So showing Initiative signals you are paying attention to the company and you are not lazy, so it is rewarded.

Through experience working with American, Nigerian and Indian developers, A common thread I have seen in the really great ones (which are expensive) is they have an insane level of initiative and the mediocre to bad ones literally twiddle their thumbs till you give them a new instruction. So it turned out good developers across the pond in India were just as expensive as the good developers in America (That is if they had not already moved to America). American companies that hired bad cheap developers ended up paying the price because developing software is both an art and science and it takes developers with initiative to create great products. So the programming jobs ended up staying home.

Now that summer is ending, this is a playlist of light hearted summer jams. Similar to the very first workstation post Popsicle.This week is focused on tracks that you would play if you were in a park with your friends playing games or sitting at your computer with your mouse in one hand and a beer in the other. Another set of sing along tracks to get you through the week.

I got my first Apple computer in 2005. It was a white MacBook from my aunt after she heard I was an Apple fan. I was an Apple fanboy in every sense of the word. I remember a friend asking me if I would go gay for Steve Jobs and without skipping a beat I responded "Wait... let me think about it" 😂. I could feel the spirit of the company, the style of the company and I resonated with their message. There was just this thing about Apple, once you understood their mission, everything they did made sense. They truly had a cult following and my theory is that they were the first tech company that took design seriously, in the true sense of the word. Steve has a famous quote "Design is not just what it looks like and feels like. Design is how it works". That quote resonated with me for years and over a decade later it influences a lot of my work today.

"Design is not just what it looks like and feels like. Design is how it works" ~ Steve Jobs

I can talk for hours about the importance of design in software but I will save that for a different day. This post is about the importance of design in order to successfully deliver software. Traditionally the media and some influencers sell software development like it is a thing about passion and inspiration. From Zuck solving algorithms on his dorm room window in the Social Network or the way the characters from Halt and Catch Fire produce one fire product after another... you know they just have sleepless nights banging their heads on the wall and boom the answer appears. Anyone who has created more than two software applications in their life can tell you this is not a consistent or sustainable way to successfully create software and that brings me to the three stages of design needed to successfully deliver software.

1. Design how the software will work: On a high level you have to talk through or scribble in a notebook how the application will work and ensure that the process it follows to function at the end solves effectively what the original problem was. For example, Instagram was originally designed with the intention to make all of us feel like great photographers with the phones in our pockets. We had these cellphones we took many pictures but they went nowhere because those pictures where whack and you can see from the very first version of Instagram filters was a thing. The way it worked remained true to the problem it was trying to solve. Designing the experience of this, the act of making people photographers with their cellphone camera is a task in itself. I cannot imagine all the temptations of all the features they could add, but having a clear design of how your app solves an issue is critical to keeping those requirements (MVP) tight and focused. It also determines how solid your architecture will be going forward.

2. Design the look and feel: This is typically what we think about when someone says they are designing an application. We worry about if the app looks, modern and trendy and has cool animations. I would like to argue that of the 3 stages of design this is probably the least important of them all. It is important for sure but clearly back in 2011 when Bootstrap was released we saw that having an original look is not critical to have a popular product on the internet.That being said, aligning the branding of your application to the issue it is trying to solve, triggers the right emotions in your intended audience and guides them into using the app intuitively.

3. Design the process of creating the project: This is often the most neglected design phase by the passionate software developer, but it is the most critical to delivering successfully. Once you figure out how the software application will work and how it will look, the next phase is to decide how you are gonna get there. Breaking the app into phases, modules or parts and deciding how each one will be executed is Engineering. Are you building your own map system or are using google maps, are you building the comment section first or last? What language and framework are best for this project? Developers always make these decisions but not many do it deliberately, acknowledging how their choices increase or decrease the chances of a successful project completion. Look at it like a recipe, if this part is well designed any competent developer can start and finish this product successfully.

These three stages of design, how it works, how it looks and how it should be built are the cornerstone to successfully completing a software project. I would argue that it is 70% of the way to successfully completing a project, whether your project becomes a success or not, that is a different discussion entirely 😅.