Instead, I prefer to look at engineers through the lens of momentum. Specifically, the dynamic between two distinct types of senior contributors: the Accelerator and the Brake.

Both are highly skilled. Both want the company to succeed. But depending on the maturity of your company, one will save you, and the other might just kill you.

The Archetypes

The Accelerator

The Accelerator is the engineer who intuitively understands the "Time Value of Shipping." They are technically excellent, but their superpower is pragmatism. They improve the output of the entire team, not just by writing code faster, but by unblocking others, making quick decisions on trade-offs, and keeping the bar for quality high—but appropriate.

They ask: "What is the minimum viable architecture we need to solve this user problem right now?"

The Brake

The Brake is an equally knowledgeable engineer. They often have a deep understanding of computer science, distributed systems, and "The Right Way™" to do things. However, the Brake slows the team down by demanding a level of technical rigour that is disconnected from the reality of the product's stage.

They ask: "How will this architecture scale to 10 million concurrent users?" (Even though the product currently has 100 users and might pivot next month).

The Impact on Morale

The interplay between these two archetypes has a profound effect on team morale.

When a team is led by an Accelerator, morale is usually high. Engineers love to ship. There is a dopamine hit associated with merging a PR and seeing a feature go live. The Accelerator facilitates this flow state. They create an environment where progress is visible and constant.

Conversely, working under a Brake can be demoralizing. The Brake often disguises their obstructionism as "mentorship" or "standards." Code reviews become philosophical debates about abstractions that don't yet exist. Simple features get bogged down in weeks of RFCs (Request for Comments). The team feels like they are wading through treacle.

For a junior or mid-level engineer, the Brake is terrifying. They make you feel like your code is never good enough, not because it's buggy, but because it isn't "pure."

The Lifecycle Paradox: Startup vs. Scale-up

Here is the nuance: You need both. You just need them at different times.

Phase 1: The Startup (The Era of the Accelerator)

In the early stages, the Accelerator is the most valuable asset you have. You are fighting for survival. You need to find product-market fit. If you spend three months building a Kubernetes cluster for a product nobody wants, you go out of business.

In this phase, the Brake is a liability. They will optimize you into bankruptcy.

Phase 2: The Scale-up (The Rise of the Brake)

As the company finds traction and matures, the ground shifts. You have paying customers, SLAs to meet, and technical debt that is starting to accrue interest.

Suddenly, "moving fast and breaking things" isn't a strategy; it's a risk. This is where the Brake becomes essential. They are the ones who spot the concurrency bug that will take down the site on Black Friday. They are the ones who insist on better observability.

The Organization Weakness: The Promotion Trap

This brings us to a critical organizational weakness observed in many growing tech companies.

As a company transitions from Startup to Scale-up, management starts to get nervous. They become risk-averse. They stop celebrating "speed" and start celebrating "stability."

In this environment, the Brake often gets promoted.

Why? Because the Brake sounds "serious." They sound like the adults in the room. When they say, "We can't do X because of Y risks," executives nod. It sounds like wisdom. Meanwhile, the Accelerator, who is saying, "We can build this in a week," starts to sound reckless to a risk-averse management team.

This is a dangerous inflection point. If you promote the Brake to a position of leadership too early, or without checking their pragmatic impulses, they will institutionalize slowness. They will build processes designed to prevent failure, which inadvertently prevent success.

How to Manage the Dualities

Leadership requires recognizing which archetype you are dealing with and deploying them correctly.

Dealing with a Brake

If you have a Brake on your team, do not let them block the critical path of feature development, especially in early stages.

1. Realign to Infrastructure: Move them to Platform or SRE teams where their rigorous standards are a superpower, not a blocker.

2. The "Why" Test: Challenge their rigorous demands. Ask them to quantify the risk. If they can't prove that the lack of abstraction will hurt the business in the next 6 months, they are overruled.

3. Define "Good Enough": Set explicit coding standards that cap the level of complexity allowed for specific projects.

Further Leveraging an Accelerator

Accelerators are your momentum generators, but they risk burnout or creating a mess if left unchecked.

1. Give Autonomy: Give them hard, ambiguous problems that need to be solved yesterday. Get out of their way.

2. Pair with "Finishers": Accelerators are great at 0-to-1. Sometimes they get bored at the 90% mark. Pair them with engineers who love polish and maintenance.

3. The "Clean-up" Tax: Ensure the Accelerator knows that if they cut corners to ship fast, they are on the hook to pay down that debt later.

Conclusion

The tension between speed and rigour is the heartbeat of engineering.

We shouldn't vilify the Brake—they are often the reason we sleep at night during high-traffic events. But we must be incredibly wary of letting them set the pace of innovation when the company is still young.

Recognise your Accelerators. Protect them from unnecessary bureaucracy. And be careful who you promote when the company starts to grow up. You don't want to accidentally pull the handbrake just as you're trying to merge onto the highway.

The Divide: Technical and People Oriented

Within the vast expanse of tech careers, a subtle dichotomy emerges, separating them into two distinct domains: the Technical and the People Oriented. The former hinges on the mastery of arranging instructions into engineering marvels, while the latter revolves around orchestrating human interactions to unravel the potential of engineering products.

The Straightforward Path: Technical Careers

For those diving into technical roles, the route to success is relatively linear. The process involves a few critical steps:

1. Acquire the Skill: The first step is to acquire the necessary technical skills. Whether it's coding, software development, or network engineering, the journey begins with honing your craft.

2. Showcase Your Talent: Demonstrating your expertise is crucial. Building a robust portfolio that showcases your projects and accomplishments becomes your digital badge of honor.

3. Break Down Doors: Hustle your way into the industry. Networking, internships, and freelance gigs can provide that all-important entry point.

4. Embrace the Learning Curve: The path from novice to seasoned professional might be challenging, but persistence pays off. Once you're shouldering clear responsibilities, you've successfully embarked on a tech career.

Navigating Murky Waters: Non-Tech Avenues

The journey becomes a bit more complex when we shift our focus to non-tech roles. The challenges are multifaceted, and a one-size-fits-all approach isn't feasible. Consider the following examples:

1. Account Executive: Non-tech roles like account executives may lack a structured path in bootcamps. This leaves beginners wondering where to start and what skills to acquire.

2. Social Media Management: While some non-tech roles, such as social media management, offer bootcamps, the sheer volume of participants can lead to fierce competition among beginners.

3. Product Management: Often perceived as structured, product management requires a unique set of skills. However, the competition arises from experienced candidates in adjacent fields.

Cracking the Proof Dilemma

One of the most formidable challenges in non-tech paths is proving your competence. Unlike technical roles, where a portfolio speaks volumes, non-tech roles often demand proof of success within established companies. This raises the chicken-and-egg dilemma.

For aspiring product managers, success is paramount, yet the path to success seems paved with uncertainty. The solution may lie in unconventional approaches such as entrepreneurship or contributing to open-source projects.

Hack the Proofs: Crafting Your Entry

Given the hurdles, a strategic approach is essential. To guide our non-tech friends onto the right track, we should encourage them to "hack the proofs." In essence, this means bending the rules of traditional proof-gathering methods and finding innovative ways to demonstrate expertise. Whether it's leveraging personal projects, networking, or unconventional paths, the goal is to create undeniable proof of capability.

Conclusion

Venturing into the tech industry, whether through technical or non-tech avenues, is akin to navigating a labyrinth. While technical roles offer a clear roadmap, non-tech paths can be disorienting. Embracing uncertainty and "hacking the proofs" can be the key to unlocking the doors to the tech world. So, for our non-tech friends, the journey is not only about acquiring skills but about creating a unique narrative that opens doors and leads to success.

FAQs:

1. Are non-tech roles as lucrative as technical careers?

While non-tech roles may not follow a straightforward path, they can indeed be lucrative. Success often hinges on strategic proof-building and innovative networking.

1. What if I lack formal education in my chosen non-tech field?

Traditional education isn't the only route to success. Focus on gaining practical skills, creating a compelling portfolio, and exploring alternative paths.

1. Is entrepreneurship a viable way to prove my skills?

Absolutely. Entrepreneurial ventures offer real-world opportunities to showcase your abilities and creativity, setting you apart in non-tech domains.

1. Can networking really make a difference in non-tech careers?

Networking is a powerful tool in any industry. Connecting with professionals, mentors, and peers can open doors, offer guidance, and provide valuable insights.

1. Is it too late to switch to a tech career if I've been in a non-tech role for years?

It's never too late. Transferrable skills from your non-tech experience can be assets in tech roles. Focus on highlighting your unique journey and how it contributes to the tech world.

I have found out that putting value for my time helps me maximize the value of that time.

This article does not mean you keep working like a robot not taking any breaks. I made a comment to one of my colleagues. What if you could cover your 8hr work load in 3 hours, but get paid for 8 and then given the chance to do anything with the rest of your day.

Another way to look at it would be: If I could complete 8hrs worth of work in 3hrs. Does that mean I am ready to take on more responsibility? Is there a promotion lurking in the corner or a case for a paycheck increase?

Think about it

I see affordable housing, food and a vibrant University community as a luxury. or more importantly, the building blocks for a new economy. As new industries spring up, one question keeps coming up.

How does Akure improve it's domestic export? How can Akure attract people from crowded Lagos to come back home and create a successful economy?

The First Few Hours.

I came 1 hour late for the hackathon.

We were disoriented ensuring everyone was registered.

We kicked off one hour later after everyone was sorted out into teams.

Internet was a challenge the first few mins, but that got better over time. The sweets did a good job at boosting morale.

The biggest 1st hour challenge was deciding which environment to use for the challenge.

The popular choices were

1. Google compute engine
2. Local machine
3. Colaboratory: Google's free python research environment.

The Next few hours

Most people had chosen to go with colab. The challenge here was getting the data into colab. A few suggestions came out

1. Upload the 1.4Gb file to Google Drive - that was proving dificult (Slow internet)
2. Use the Kaggle CLI - also tricky setting up Kaggle cli to work in collaboratory
3. Using Good ol python file download.

A team came up with a Kernel on Kaggle for pulling the data, most people ended up using good ol' python for this task

I Lied

I did not think up this problem, I was contacted by a lady with this problem, and I opted to find a solution to it, but asked for credits in this work and she agreed to it, so my challenge begins. To get started, I will be starting the first generating a dataset that I can use to explore this problem.

The Plan

This is less of a plan and essentially the progress we have made. The first step here is to generate 10k microsoft word documents. I don't know how to do this so I got the help of my friend John Oke who completed the task - like a bad guy in under 3hrs, I was really impressed. Now I have 10k documents on my laptop containing random texts that poises the next level to the understanding the problem.

The Next thing I will do is get this files into python's HDf5 format, which data scientists have been preaching about for a while. Each file I generated is around 12kb, making it manageable for me to work with. This clean working documents will serve as my positive set. I will also copy them to the corrupting flash drive to ensure that they go bad. I have a theory that not all of them will not be unreadable, but hey, that's how things work in real life, data does not usually come back super clean.

Quick answers:

Is this code on GitHub: Well, yes it is here: https://github.com/e911miri/word-generator

Who is the mystery lady with this project: Well that's classified :p

Do you intend to complete this: I don't know, it sounds like fun, so I am taking it up.

Where can I learn more about machine learning: There is an amazing course on Udacity

The corrupt document

Every once in a while or approximately 1 in 10 flash drives / memory cards, documents copied onto a flash drive no longer retains their form. In order words, they are corrupt and cannot be read easily by microsoft word or vlc without a special voodoo operation. Once a flash drive starts to exhibit this behavior, the owner cries for about a day or two and keep the flash drive at the bottom of his bag hoping that one day, the old documents would be retrieved by a magician.

The curiously missing document

This one is even more popular. I would approximate its occurrence to be at 3 in every 10 flash drives that are used on private windows PC and 8 in every 10 used on public windows PCs. Surprisingly, these files are accessible on Mac and Linux. What causes this is a tiny malicious process that hides all folders in the flash drive and creates a executable clone with the same image as a windows folder. This malicious program does this to trick other flash drive users into installing itself and thus propagating its life cycle.

This scourge can be prevented by not opening flash drives directly. If you are a victim, you can either install a recent antivirus or run command task manager, locate the malicious program and terminate it. Stop from starting either as a service or at boot time. Finally, clean up old flashes by deleting the windows folder looking executables and run attrib *.* /d /u -h -r -s in an elevated command prompt window.

Glossary

a special voodoo operation: Refers to a theory in my head that the document can still be recovered by special computer nerds, if not, how come we see people in movies recover memory files from corrupt or broken or exploded hard drives.

Reason for writing this post: It just popped up in my head and it seems like an interesting topic to write on.

I have checked out Free Code Camp and it does not contain the competencies that I am looking forward to build. Don't get me wrong, I have not mastered all topics covered in Free Code Camp.

The next stop was DataCamp, which I found by googling Kaggle tutorials. The intro video seemed promising. I have always wanted to master plotting in python and the first video marketed that I could create a really cool chart by the end of the chapter.

I was excited to follow through till I hit the next roadblock. If all the code is going to reside on data camp, h0w do I get it to github, or better yet, how do I ensure that people can use it. I guess the separation here would be that I write the code in a repository and write a simple guide for running the code that I put there. See... It really pays to write.

Wow... It's been 4hrs since I wrote the last one. My blog was using an oldish version of ghost. After toiling and installing a vm, I finally got it upgraded. This took more of copying and pasting than actual coding, so I wonder what the folks doing this challenge feel about it. The source code

I will be documenting my progress on github. I choose github because that is where a lot of open source projects are hosted. In my code, I aim keep it as simple and as educative as possible. In that way, I can strike a healthy balance between challenging and educational.

Many of the code I will be writing might be generated from IDEs - an example would be the storyboards / xib files. Some might be data driven - You'll find this when I am working on machine learning / data science challenges. Others would be in a plain general purpose language like python.

I also intend to write healthy volumes of READMEs, because I want to get better at writing and expressing/articulating detail.

If all goes well, in 100days, I would take 1 day to celebrate this, and more than likely try to convince 100 people to try out this challenge. Now you don't have to wait for my 100days, you can also start this challenge today. Kallaway has a healthy getting started guide which I am following.

Much Regards

What apps are being curated?

My class has 3 active groups working on 3 web apps.

1. Team Alpha is building a portal to locate emergency centres around you.
2. Team Beta is building a mobile app that will help you detect if a consumer product you bought is fake / expired.
3. Team Theta is building an information portal that will help provide farmers with information that will maximise their yield.

The abstract parts of programming is pretty easy to learn.

It becomes harder when you combine it with an actual programming language. We had girls learning things from variables, to conditionals to iteration to functions within 20mins. They however had trouble when Javascript compiler did not understand the english they were typing into chrome dev tools.

Design is surprisingly hard

It was my initial assumption that designing websites was a relatively simple task. I always focused on the part I thought was harder - backend development. I spent a lot of time before remembering that <link> is different from <style>.

It always pays to prepare

I spent a lot of hours preparing for my first class, however, upon appearing at the class, I found out that much of the knowledge I planned to share would come across as too much. This led me to research a lot on how to introduce web development to complete starters. The experience was both enlightening and refreshing.

Start with the end in mind

Now often, newbie designers tend to just wing it as ideas pop into their heads, what ends up happening is a chaotic design with no clear flow or intention. When approaching design problems, start with one step at a time having a final picture in your mind... The simpler, the better. Then try to complete that picture before pivoting. If it is hard, then you might have missed something. That brings me to the next point

Good design language is your best friend

While we are often tempted to be creative, it would be really helpful to follow design guidelines. One I find helpful is the material design guidelines made popular by google at https://material.google.com. Different aspects of it has been implemented in different frameworks each of which has its unique strengths and weaknesses. For example, google has some really neat paper elements as components for polymer (https://polymer-project.org) - it is neat but a bit tough for someone without JS experience. Materialize css(http://materializecss.com) is simpler but does not contain as much features as paper elements. It comes down to choice.

That's it from me, once again, thanks for taking time to read my article

November 2014, I had a similar problem. He who must not be named handed me a contract to seal up broken pipelines within the system using nothing but php and mysql. It was my 3rd week writing php in a production environment. What am i going to do? How do I even understand how this works? Finally, what do I do next, the whole system is crawling - This were my expressions on that day.

Fast forward 20months. We are pretty comfortable with the new codebase, support is really cool, we have on boarded two new engineers and a lot of clients and customers, we now communicate with more systems, our apis are documented and developer friendly but - Unit Test coverage is at 39%.

Unit Test coverage is at 39%

We need to up that number to something significantly greater than 70% to get a few boxes of pizza and that our conundrum. But don't fret, we have a plan.

The Plan

1. Delete all unused code - We will enjoy that
2. Prioritise tests for our models
3. Prioritise tests for components
4. Ignore controllers
5. Ignore background jobs
6. Check how well we are doing and rework our strategy

This is not the first time we promised that a sprint will take two weeks. By now, someone might be wondering - what is he talking about? what is a sprint. Not to worry, a sprint is a short time commitment a team makes towards delivering an agreed amount of work. It is a term popular in agile software teams running on steroids. Roughly 6weeks ago, we committed to delivering a set amount of work in two weeks. We had the usual sprint planning meeting with our product manager and designer and we agreed - though grudgingly - we agreed, I can't believe we did agree.

Two weeks ago, the mercury team set a target to deliver a new feature which we believe would up delivery time by over 40%. This means that more than 40% of our customers would be likely get their packages 35% less time than before. We were all beaming with smiles and wanted to achieve this. So with enough motivation - the general zeal towards doing good, we began the sprint. We spent most of the first day arguing, naming variables and data columns, agreeing on api endpoints and contracts and of cos celebrating my new car :)

So how did we pull this off?

Day 1: Argue a lot

Day 2 - 4: Complete 80% of the work

Day 5 - 7: Man down :( Write a tonne of unit tests

Day 8: Bash the hell out of Q/A :) and hound our PM for pizza

And that's it, that's today's article.

Tomiwa Ijaware's Portfolio website.

Imagine her clicking on your website.

Just imagine you had this amazing person who wanted to learn more about you. You have spoken a lot about how awesome you are and now it is time to show it. to do so, you need to have a website that says one simple thing. What have you been up to.

Integrate Google Analytics

Now you do not need to imagine what she is doing, because you can see what she is doing and even see it for free. Please tell me you hooked up GA to your website. I didn't but you should.

Nice UI - Polymer Starter Kit

This is an awesome kit that greatly improves the look of your website. you can focus on what's important. For example, now that I have this view up, my next target is to allow engagement.

At the #gdgsummit, I was privileged to have attended this session and I was totally amazed by how much it taught me. But beyond knowledge, we were able to think up solutions to a problem we decided upon using intriguing tools. I was so amazed by it that I feel that these creative skills are a key ingredient towards the rise of Africa. I cannot remember the history of CSI but I remember the lessons I learnt through the activities and I’ll be applying them to ideas i’ll have in the future._

PS - I cannot remember so much so I’ll to write from what I have learned._

LESSON 1: Courage to dance Shoki

In our lives, we are constantly surrounded by leaders who decide to act on what they believe in. From mothers who ensure they have bright young children to the boy in the park who starts doing a weird dance with enthusiasm. While everyone could relate to mothers, I want us to take a look at this young boy.

I was walking in the park when I saw a young boy doing this weird dance. He puts his left hand forward, then sways from side to side. Next he was doing light jumping movements with swag. I thought the dance was stupid but he was really enjoying himself and having fun. Before I knew it, a Young boy slightly older than he was stepped forward to join Jake in this dance. They were both so happy. It was no longer one but two people. Blaine signalled his two friends and then they jumped in. From one, it had become two and from two, four weird dancers. I felt the rush and I joined in, not just me, but three other people joined in with me. The numbers moved from 1 to 2 to 4 to 8 to 15 till almost everyone was dancing that wierd dance (wierd dance = 'shoki').

The lesson learnt here is that we should have the courage to stand for what we believe in, and also the courage to join another person who is doing what we believe in.

LESSON 2: The crowd of Rock Paper Scissors

This story was at the #gdgsummit. Over 600 gdg leaders from different countries gathered in a room. A game was declared. Pick a partner and play rock paper scissors with one another. If you lose, you cheer the winner and get your champion to compete with another champion. You keep cheering till you are cheering for the ultimate champion.

You can try this at your next GDG event in a CSI Lab - I would :)

CSI Labs

Objective: To find out what how we as gdg leads can make our members have an engaging experience at our events. Time Allowed: 2hrs Team Formation: 8 gdg leads from different countries selected using a mystic algorithm.

TASK 1: Identifying users

This task involves reflecting on our previous activities and identifying users that come to our gdg meetups and in my team, we found a couple

• The Student
• The Employed person

TASK 1.1: Interviewing

I can’t believe I missed this - You need to interview users to find out their needs

TASK 2: Identifying needs

We wanted to know what our attendees want that bring them to our meetups and in my amazing team, we found a couple too

• To learn about new technology
• To network with people
• To Find Jobs or Employ people
• To share knowledge
• To get fame and notoriety for community participation

TASK 3: Creative Solution

Here, we made use of post-its. We were to come up with a solution to the needs we listed here. This required some coordination to encourage collaboration. To help with that, every one says his idea aloud before sticking it on the board, anyone can add to the idea but no one is allowed to criticize it. That way, there was a rich collection of ideas. Here are some from my wonderful wonderful team :)

• Apply gamification to attendance
• Organize coding dojos
• Reward mentoring
• Invite GDG speakers from other countries to speak
• Organize product driven hackathons

TASK 4: Rapid prototyping

It is rapid - You’ve got 15mins to prototype your app and get it ready to be tested by actual users. You’ve got many weapons

• Paper prototypes
• Mockup tools
• Cardboard prototype
• Something called Pretotypes
• Click through prototypes

We chose paper prototyping to represent our solution and guess what we prototyped - A gamified attendance monitor for GDG members, isn’t that amazing?

I really hope you learnt quite a bit from this writing and I do hope you try this session in your GDG

If you are like me and erased your entire harddrive, and you no longer have rapid response working, here's how to get it back1. Run the diskmgmt.msc command and delete all partitions from your SSD2. Shrink your primary Harddrive by 200mb3. Install Intel Rapid Storage Technology4. Launch Intel Rapid Storage technology5. Click on the Create Button and Follow the Prompt.

If this process does not work, leave me a commentFor a while now, Intel has been producing computers with much faster read/write speeds. This is made possible by pairing a relatively slow and cheap hard drive with a small and really fast solid state drive, SSD. The SSD provides really fast read/writes by caching frequently accessed data, which gives you a burst of up 10x your HDD speed.

If your computer has this, you;d see something like 19/24/32Gb SSD Cache depending on how generous your manufacturer is.

Managing SSHDs

Intel provides two bits of software for managing

1. Intel Rapid Start, Usually available at the BIOS
2. Intel Rapid Storage Technology

Rapid Start allows your computer boot up in seconds by storing windows boot information on the faster SSD drive.

Rapid Storage Provides you with Rapid Response Technology. Rapid Response Technology is what Intel uses to speedup harddrive read/write

Today, One of my favorite mentors created a startup in django and moved it to flask, more of that story is but here's my version of the story.

I started anything with python after a short presentation at Devfest Lagos 2010. At that event, I learnt how to bootstrap a simple web application in a few minutes, with under 20lines of code, I was super amazed and since then, I have been encouraging everyone to learn python.

I claim to be a web developer and that pushes a lot of projects my way, I initially wanted to do everything with appengine until I discovered django. Django is a web development framework for perfectionists with a deadline ... I mean... that's the perfect way to get me hooked.

Anyways, I got into building websites with django and I got to love django-admin, heroku is my friend, so is sendgrid and celery (don't worry if you don't know what they mean) unitl something happened

Traclist was like my applications originally built with django, but the founder of this startup has decided to migrate it to something faster, Why would anyone think Django is not fast?

His startup explains with significantly more data some of the pains of scaling a django application.

Meet Randall Degges

1. What happens to people who bought at $1200

2. Will this decline be temporary or are we looking at another bitcoin crash?

This situation is tricky, my stance is that bitcoi value is going to rise again sooner rather than later. My claim is based on the trends I have been watching for the past two months, periods like this happen. These declines will soon be over. I won't be surprised if the value of bitcoin shoots past $2000 before the end of the year