Check out Annie: https://anniemusic.app/. Make sure to leave any feedback you have on it here.

You can get the recorded session on Youtube (embedded below)

Stay till the end of the recording to learn from the Q&A segment.

Questions asked:

1. I always wonder what goes into making the decision on which platform to start building for. For example, why did you guys decide to go with Apple first?
2. Have you monetized this? If so, how? If not, what's the plan?
3. How do you judge if the problem affects enough people to make it worth solving?
4. How long did it take you, from the ideation stage to actual implementation?
5. Do you have a specific framework that you use to ensure you adequately understand a problem?
6. Curious about the mental toll creating this app has taken.. you mentioned something on not having the confidence ... if you don't mind could you share more?
7. Is there a simple software architecture plan you had before making the MVP and or the proof of concept?
8. How often do you perform status checks of the problem to ensure you're still "on track"?
9. What was the cost of creating the app?
10. What is the current usage like? and what is the feedback from your current users?
11. What were key lessons you learned building this product in terms of keeping the product on track, considering that the product was mostly built as a side project?

Building a software solution

• Understand the problem

It's commonplace to find people coming up with solutions to abstract problems OR problems that do not exist. While building software you want to identify a problem - the best way to do this is to ask yourself what is a pain point you have, and sure enough, most times, if it's something you are facing a lot more people are also struggling with it too. After identifying the problem, you want to flesh it out, this helps you understand the problem wholly and will be instrumental while building a solution to it.

Bolaji gives us an apt example:

Say you identify that your AirPods battery drains too fast and are hell bound to come up with a solution for this. 💡 You quickly come up with a fix, let's just hook these up to a car battery, and now the charge on my AirPods last way longer. If you had taken a beat and sat with the problem, you might have noted the reason people use AirPods, is that they are lightweight and easy to port. Your solution, in this case, solves one problem but introduces another / completely negates the initial use case of the AirPods.

You can see why understanding the problem and the problem space plays a big part in the solution you end up with. The better knowledge you have, the more likely your solution will serve the needs of your users.

Some example questions you want to ask yourself in order to fully understand the problem are;

1. What kind of battery does the AirPods use currently?
2. What are the other kinds of batteries out there?
3. What is stopping Apple/manufacturers from using the alternatives?

• Check for existing solutions / current workaround

Since this is a problem that people face, there must be a workaround and/or existing solutions to the problem.

Take Annie for example, to share a song one is listening to you might find people taking a screenshot of the song on their streaming app and sharing the image, or one might have to actually type out the song name and artist and text that to a friend. Knowing this, Bolaji and the team started thinking of how to streamline this, by having the user share their song using the least number of clicks possible. When taking a screenshot and sending the image, the user will have to click for the screenshot → navigate to their messenger app → search for the screenshot → then actually send the screenshot. This experience would take at least 5 clicks. When thinking about Annie the goal was to allow a user to share their music in under 5 clicks.

The takeaway here is, if you have a solution that doesn't offer a better experience, then all you have is a new shiny solution, which really doesn't have anything to offer that's better than the existing user experiences. To get users to use your app you want to give them a demonstrable better experience. So it is very important to do your homework in regards to existing solutions in order to have a competitive edge/advantage. It may also lead to more insight into the problem, as you will take time to understand why the current solutions have been architected in a certain way.

• Figure out your approach towards the solution

Given that we now understand the problem, and have identified and studied existing solutions we need to figure out how we want to solve the problem ourselves.

For Annie, Bolaji and the team figured out that users aren't able to share songs easily. The problems users have while sharing included;

1. If person A wants to share a song, eg. 'Champion' when telling person B about this song, person B types in the name Champion onto their streaming platform and they find 10different songs going by that name. How does person B figure out which song person A meant to share?
2. Sometimes when listening to a song you do not know the name of the artist. To figure out which song this is you first need to Shazam it, then send it to the person you want to share it with. This can be a pain as you end up having to juggle between multiple apps to share a song.
3. User error - misspelling of artist and song names
4. There are many streaming services and to share a song you might have to first establish which streaming service person B is on before being able to share a link to the song.

In comes Annie, given a song, Annie doesn't just provide a Spotify link, apple music link, or a Deezer link - she generates a generic link that can be used on all the streaming platforms. So basically, when sharing music you don't have to first establish which streaming platform the other user uses, with one link you can get the song on any of the aforementioned platforms. This is Annie's edge over the competition. With existing solutions, it's still a pain to share music because you have to establish which streaming platform you want to play the music on. People who share playlists, traditionally have to create the playlists manually on each of the different streaming platforms they want to share on. As you can already tell, that is a big pain that Annie is going to be a solution to.

• Create a product plan

Now that we have the solution, it can be very tempting to jump right into building it. However, you need to take time to figure out the direction you want to take when building the solution. During this stage, we want to take off our software engineering hats and put on our product owner hats. You could alternatively hire a product manager on your team.

Having a product plan helps us at the early stages think about why we are building the app in a certain way, the tradeoffs we have on decisions we make early on. For example, we might want to look into whether we want to build an app for mobile rather than web initially, thinking about these things early on and making informed decisions will in the long run increase the chances of making the app a success.

• Build an MVP (or proof of concept)

This gives you confidence in your product. It's the most lightweight version of your solution. It doesn't have to be perfect, just a working version of the solution.

• Test it out with friends and colleagues

With the MVP, you can share it with your friends and colleagues, to get feedback both positive and negative. At this stage, you can tell whether people are actually interested in using your product. It's a good way to dip your toes in the water and test out whether your solution actually works.

• Iterate

As people use your app, from their feedback you can iterate and make your app better. With the product plan in place, you can also easily sleuth out which feedback is relevant to what you are building and add the ones that fit your plan into the product development schedule. It's important to focus on your core solution, make it perfect, before trying to look into other related areas. The product plan should keep you in check on the initial idea and the areas you want to focus on.

Annie is currently on its 5th iteration. With the first iteration, you had to manually share the link to a song by copying it from the streaming platform into Annie. From user feedback, the team learned that this was a pain users were having and enabled the sharing of links directly from the streaming services into Annie. Note that the iterative way of building an app allows you to make improvements while still having a pulse on how users feel about what you are creating. This guarantees that your solution is effective and actually gets used.

Focus on the problem you're solving and solve it well!

1. Finding ideas

Finding the right topic for your workshop can be the biggest reason for procrastinating doing one. Often times, however, the ideas are all around you. One great source of ideas is from your day to day work. What interesting library or framework are you using? What’s an interesting infrastructural problem you’ve resolved recently? Maybe it's meta, how did you improve how you’re measuring and estimating levels of effort for work? How did you improve your code review or hiring processes? In other cases it could be more soft-skill oriented or personal – how did you grow your impact in your team last year? How did you make a transition from software development to product management? What has managing teams taught you?

The list is endless and as long as you’re learning, reflecting and growing, there will always be something you can teach others. Make sure to write down all the ideas that come to mind over time, research them and read what others have written about the topic, saving bookmarks while you’re at it; they’ll come in handy. If a given topic has been exhaustively explored by others, you may still have a differentiating experience with it so avoid binning such ideas prematurely.

When it comes to choosing from your list of ideas, you can weigh each against the impact compared to the level of effort required to prepare it. If it’s your first workshop choose a low-effort idea to make it easier for you to build momentum for higher effort ideas in the future.

2. Define your audience and your goals for them

What’s their experience level? Are they beginners, intermediate or advanced? Do they need some preliminary knowledge to make sense of your presentation? Identifying the goals for your audience is important in helping you better define who they are and better refine your content for them.

For example you may be conducting a workshop on multiplication (the mathematical operation). Some of your goals might be that by the end of the workshop the audience:

• Will be able to multiply single digit numbers
• Will be able to multiply more than 2 numbers together.
• Will be able to multiply negative numbers
• Will be able to multiply fractions

Identifying goals and cases, you will uncover that perhaps your audience is better off memorising the multiplication table or that they may not understand fractions and negative numbers or that you may need to explain the order of operations or that you may need to explain multiplication in terms of addition and so on. You will find that each goal can be expounded upon even deeper but your audience’s experience level will determine how deep you need or want to go e.g. you can cover multiplication of proper fractions but mixed fractions may be out of scope.

This process of breaking down goals for the audience will feed into the next step of creating an outline.

3. Create an outline

Here's a generic structure for an outline:

• Introduction
  • Introduce yourself
  • Introduce your topic and what you’ll be covering
• 1st main idea
  • Theoretical explanation
  • Exemplification from the real world
  • Illustration/exercise (diagram, flowchart, code sample/challenge, analogy, anecdote)
  • Optional supporting idea and/or practical step
    • Explanation and illustration

• 2nd main idea

  …

• Summary of learned skills

• Q&A (question-and-answer)

When starting, it’s important that the audience has an understanding of your level of expertise, background and motivations for the workshop like whether you’re representing your company or will be pushing certain products during your presentation. So begin by introducing yourself then introduce your topic; what you’ll be teaching your audience and your goals for them.

From there, you can begin digging into the substance of your workshop . A good framework for helping others understand complex concepts is the SEE-I method where you take the audience from the theoretical elaboration of the concept then a real world example then an illustration or exercise. Since it’s a workshop and your goal is to impart skills on your audience, err in favour of practical hands-on illustrations that your audience could do or see you do or pose questions to them to keep them on their toes. Of course, the SEE-I method's steps are not set in stone and in some cases where the explanations are too complex or irrelevant for your audience you will be able to do without some of the explicatory steps.

At the end of your presentation, summarise what the audience has learnt and be ready to field their questions.

Here’s a more concrete example outline for a talk titled “Version Control with Git” an intro for beginners (feel free to skim over once you grok the idea):

1. Introduction - 3 min
   • Who is Jane Doe?
   • Objectives for today
2. What is git? - 10 min
   • Git is distributed version control. What is version control? What makes it distributed?
   • Why do developers use git?
   • Visual diagram demonstrating problem of 3 people adding lines to copies of the same file and how they need to reconcile changes when bringing it back together.
   • Let’s install git
     • Run command to install git
3. How does git work? - 20 min
   • Initializing the repository
     • Run git init and describe what the command does; places .git folder in current directory.
   • Adding a new file to the repo
     • Run git add command and describe what staging and the staging environment are. Illustrate using git status.
   • Committing staged changes
     • Run git commit and illustrate using git log to show the created commit
4. Git branches - 15 min
   • What is a branch?
   • How are branches used?
   • Visual diagram demonstrating tree with 2 branches containing the same set of commits and how their histories diverge upon changes to one of them.
   • Let’s create a branch
     • Run git branch command to show all existing and currently checked out branches. Explain branch naming conventions.
     • Run git branch to create new branch following naming conventions. Run git checkout to switch branches and ask audience which command can be ran to prove the branch actually changed.

5. Syncing to remote repositories - 7 min

   … (other content)

6. Summary - 1 min
7. Q&A - 10 min

When writing out your outline, it is imperative that you allocate some time guesstimates for each section based on the total time you’ll have allocated for your session. It'll help you stay on schedule and trim the fat where the time is exceeded. The estimates won’t be very accurate in this initial draft but they’ll help you figure out what’s important and quantify the density of each concept. Editing is king and you should iteratively refine your outline, furnishing it with some margin notes where necessary.

4. Prepare the outline's content

An outline is like a skeleton that needs to be filled up with actual content so prepare the proofs of concept, code samples, questions for the audience and exercises that you’ll be going through in your session.

A slide deck is a really convenient way to pace yourself and deliver your content's key conceptual points. It’s also important that your slides are accessible, in terms of legibility, contrast and font-size. For that, you can find free slide templates on slidesgo.com that are also visually consistent and captivating.

Your diagrams and links to code samples or repositories will go on your slides. You can use free tools like Github Gists for smaller code samples or a Github repo for larger projects and diagrams.net (formerly draw.io) for making diagrams.

After the session it would be valuable to share the slide deck for the audience to revisit. If your presentation software has a speaker notes feature make sure the notes are intelligible for other people! Here is a list of other anti-patterns to look out for when making slides.

5. Rehearse

By this point, your workshop will have a reasonable semblance of completion but it’s not done yet. It’s time to rehearse the presentation. You can do this on your own but you’ll have better feedback by having at least one other person you trust listen to it. During rehearsal, avoid long stops to correct issues you find but instead take short notes that you can revisit later. Take note of how the presentation flows; whether certain subtopics need to be reordered, things that sound ambiguous or slides that throw you off and feel incongruent with the idea you want to deliver.

In addition, practice the audio-visual tools. You don’t want to be fumbling for the "share screen" button on Zoom during presentation. A neat lifehack with Google Slides is the presenter view where you can view your speaker notes on one window and the actual slides on a different window and any transitions you make on the speaker window will change the current slide on the slides window that you’ll have shared with the audience.

Having finished rehearsal, you'll have a better idea of the time-boxes you estimated for each section and resize them accordingly. You will also have caught grammatical errors, smoothened out the flow of your presentation and ultimately have a finished product!

Conclusion

With the right preparation, conducting an online workshop can be less nerve-wracking. It’s a really important skill for developers to have since our industry is founded upon and grown by the free dissemination of information and ideas – amongst other open-source principles. I wrote this because I believe everyone's ideas are valid and valuable so by refining our presentation skills we increase our capacity for impact. All the best with your workshop and let us know how it goes in the comments!

Our Speaker is non-other than Charles Kithika, an experienced Software Developer, Product Manager and Chief Innovation and Product Officer based in Nairobi, Kenya. Charles will be taking us through several concepts a consultant needs to be familiar with from starting out, finding and growing your market, project management and handling your clients.

The talk is very informative and will cover a variety of concepts that will be useful to consultants in a variety of fields. You can find the talk slides here and watch the video call on YouTube here:

Collins is a software engineer, Internet entrepreneur, and strong proponent of documentation and TDD (Test Driven Development). All this can only be achieved by eliminating distractions and minimizing context switching making Vim his tool of choice.

We were live on Youtube. Check it out for the full conversation.

Key takeaways:

1. Speaker's Bio. Give him a shoutout @kaka_ruto on Twitter.

2. Tips to customize and configure Vim as desired to suit your style.

3. How to get all you work goals executed through a Shell i.e Create, Read, Update, and Delete with Vim.

4. Resources on Vim to help you build your muscle memory to achieve speed, productivity, and focus.

5. Check out the slides for more.

Q/A highlights:

• What are some of the plugins used to make Vim more appealing to users?

In case you have questions that were not addressed, hit the comment section to receive feedback on the same. We look forward to comments here or on Youtube about what topics you would like us to speak about next.

Stay tuned for more workshop forums like this every first Wednesday of every month. Watch our other sessions in this playlist.

Cheers.

The session was recorded. Watch it below:

Watch other Workshop Wednesday sessions in this playlist.

Our speaker today is Mercy Muchai, a software engineer based in Nairobi. She is currently specialised in web development and enjoys singing and playing the piano when she isn't building features and squashing bugs. She will be taking us through everything we need to know about getting started with Typescript.

You can watch the video call recording on YouTube here:

Our lead speaker's professional journey began a decade ago from Software Engineer to Engineering Manager to Technical Product Manager to Product Manager and now Chief Innovation and Product Officer at Longhorn Publishers.

I'm talking about none other than (drum rolls) Charles Kithika.

We were live on Youtube. Check it out for the full conversation.

Key takeaways:

1. Speaker Bio info. Give him a shoutout on Twitter .
2. Who is a PM?
3. Day to day of a PM - Task Prioritization and data-based decision making being on top on the list.
4. Preparation and transition to the PM role, things to do before the switch.
5. Do's and Don'ts on the Job.

Check out the slides for more.

Q/A highlights:

1. How do I step up to act as a PM in a company that doesn't have one? and how do I balance being a PM and a dev?

2. How do you as a PM handle a demotivated team especially after missing a deadline or getting a bad review on the progress you thought was amazing?

3. How to handle any tension between Engineers and PMs?

4. How should developers interact with PMs?

In case you have questions that were not addressed, hit the comment section to receive feedback on the same. We look forward to comments here or on Youtube about what topics you would like us to speak about next.

Stay tuned to more workshop forums like this every first Wednesday of every month.

Cheers.

Here's what went down today: developerISH meetup #1

Speaker

Ryan Marvin

• Twitter account
• Hashnode account | Blog
• Github account

Talk

Ryan Marvin (of course after introduction) took as through:

• What Serverless is all about
• Serverless frameworks out here
• Code deep-dive for a simple web app that allows users to get weather updates periodically
• Gotchas and limitations of Serverless
• Introduced us to a tool servers.lol to figure out if Lambda is for your case scenario

Watch the recording below:

Additional resources:

• Slides
• API repo
• UI repo