Coders for Causes BlogAbout

It has been a while since I posted on this blog. Hopefully I can get back into it :) Running projects require a different skill set than programming. Here are some things I learnt while running projects for Coders for Causes

Learnings regarding students

• Its hard to conduct workshops. The most effective way is maybe to copy frontend masters where the presenter talk for a bit, write code then gives out exercises where they can then walk around and mentor people and go through the solution
• 1 on 1 programming is effective in teaching people how to code

• We need to motivate students more

  • Designating times where everyone comes in. Maybe 3 times a week
  • Get big name companies in so they want to do well to impress them

• Possible effective workflow

  • Build a basic project scaffold for them to work off so they can follow the best practices and its easier for them to get started
  • Use a physical board for task tracking
  • Everyone pushes to master but everyone is also paired up. Especially initially when code constantly changes
• Its hard to manage a large group of students

Managing Client Expectations

Clients don’t have a lot of technical knowledge so we need to inform them and continually inform them of the best approach to things. We need to also educate them a little in software. Here is a checklist we need to convey

• Sometimes we need to push back on features that are not important in order to be efficient and deliver the best possible product in terms of reliability, maintainability and usability. It is very easy to waste a lot of time building a low impact feature so we need a disciplined process to determine how meaningful a feature is and how much time it takes for the programmer to make.
• Software is very hard to build well. Thats why you constantly see bugs and websites getting hacked for example linkedIn losing millions of passwords https://en.wikipedia.org/wiki/2012LinkedInhack Facebook storing passwords in plain text https://www.theverge.com/2019/4/18/18485599/facebook-instagram-passwords-plain-text-millions-users and the bug in IPhones that allowed people to eavesdrop on others https://www.zdnet.com/article/iphone-facetime-bug-now-apple-sued-over-eavesdrop-on-lawyers-client-phone-call/. Bear in mind these companies have the smartest people with the most funding. So it is important that you as the client understand these points so they can help us in building the best possible software application with our given resources.
• There will be bugs mostly small ones but occasionally there will be the big one. The reason is because it relates to the first point, building good software is hard because its very technical. This means its easy to get things wrong due to oversights or lack of understanding. Therefore we need a strategy to minimise the impact of bugs and to catch them. The most obvious one is rigorous testing. We need tight feedback loops between building a feature and user testing.
• You need to ask yourself do you really need programmers? There are a lot of easy to use websites and tools to help you create websites and applications for example SquareSpace and Wix. Since building software is hard it can be a stressful process for both the clients and programmers so you need to consider this carefully. Hiring programmers allow you to build customised solutions for example it will be very hard to pull data from your company database and display it in a chart on the website securely. They can also can give you guidance on how to build a secure, scalable and maintainable solution.
• Building software is also a discovery process. The idea you had will likely change when it takes shape. For example you wanted to build a chatbot for students but as you test it you find out that students don’t like chatbots and won’t use it. Then you have to pivot and you find that a mobile app would be a better choice to engage students.
• What exactly can software developers provide? Good ones can build out whatever your idea is. It won’t exactly match your idea to the pixel but the main features will be built. There will be minimal bugs and the features will be delivered in a timely manner. They can also provide you guidance both on the technical and high level on how to build an software application
• Be mindful that seemingly simple changes may not be simple to implement in code. Try not to assume that the programmer is being lazy (if they are a good one) when they pushback on your simple request. For example moving a text box around. This seems really simple and you can easily do it in photoshop but at a code level it may not be because the programmer has to consider the optimal location on all devices. The text box also won’t magically resize they have to code it. Finally software development is very broad they may not be knowledgable in coding layouts.

Potential Action Items for Next Project

• Use a more effective workflow
• Keep groups small e.g. max 5 people
• Get big name companies involved by giving workshops (issue since we are reducing the number of people it may not be as attractive for them)
• Give a week or two worth of workshops before the projects in the style of frontend masters
• Be physically available to mentor them
• Designate 3 days a week to have the group come in to work

Written by David Yu who loves to build things in code.You should checkout our facebook for latest events and news