Taking a break is a great problem solver in the software world

When you are writing code encountering challenges and roadblocks is inevitable. Whether you're a seasoned developer or just starting your coding journey, hitting a wall in problem-solving is a shared experience. In these moments, the inclination might be to power through, burning the midnight oil to conquer the issue at hand. However, there's a powerful and often underestimated strategy that can make all the difference – taking a break.

Mental Fatigue and Productivity

Solving complex software problems requires intense focus and mental energy. Continuous engagement without breaks can lead to mental fatigue, diminishing your cognitive abilities and creativity. Taking a break allows your mind to reset, helping you return with a fresh perspective and renewed mental stamina. This can significantly boost your overall productivity.

At Kaz we are serious about taking breaks during work. Our work environment is designed so that there are spots where someone can just sit and relax or play a game to take their mind off work.

Gaining a New Perspective

When you're deeply immersed in a coding problem, it's easy to develop tunnel vision. Taking a step back provides an opportunity to see the bigger picture. A break, whether it's a short walk, a snack, or a brief diversion, allows your brain to process information in the background. Often, the solution to a problem becomes clearer when you're not actively focusing on it.

Preventing Burnout

Software development is demanding, and burnout is a real risk. Constantly pushing yourself without breaks can lead to exhaustion, decreased job satisfaction, and even long-term health issues. Regular breaks act as a buffer against burnout, preserving your passion for coding and maintaining a healthier work-life balance.

A great way to prevent burnout is to take a long break from work - like a holiday or even a short staycation. At Kaz we do our yearly anniversary party as the company-wide long break, where we go somewhere far away for a few days to just relax and not talk about code!

Creativity Flourishes in Downtime

Creativity is a crucial aspect of problem-solving in software development. Breaks provide the necessary downtime for your brain to make unexpected connections and generate innovative solutions. Some of the best ideas often come when your mind is relaxed and not fixated on a specific problem.

Improved Decision-Making

When you're stuck in a coding dilemma, the pressure to find a solution quickly can cloud your judgment. Taking a break allows you to step away from the urgency and approach the problem with a clearer, more rational mindset. This, in turn, leads to better decision-making and more effective problem-solving.

Physical Well-being

The sedentary nature of software development can take a toll on your physical health. Many tech companies are introducing standing desk as the cure for cancer for this, but it’s not really a proper cure, a great read is this article on Harvard Health Blog about standing desks. The truth is that you need breaks away from your desk and work. Regular breaks promote movement and help prevent issues like eye strain, back pain, and repetitive strain injuries. Simple activities during breaks, such as stretching or taking a short walk, contribute to overall well-being.

In the world of software development, the ability to navigate challenges and solve complex problems is paramount. However, it's essential to recognize the value of stepping back and taking breaks when faced with a programming roadblock. Not only does it contribute to improved mental and physical well-being, but it also enhances productivity, creativity, and overall job satisfaction. So, the next time you find yourself staring at lines of code with no solution in sight, remember that sometimes, the most effective solution is to step away and allow your mind the space it needs to conquer the challenge at hand. Happy coding, with a healthy dose of breaks! Remember those old KitKat ad? Where they used to say “Have a break, have a Kitkat”, that’s exactly what you need to do!

Living with Bugs: Navigating the Imperfect Landscape of Software Development

In the intricate realm of software development, bugs are not just an occasional nuisance; they are an inherent and inevitable part of the process. No matter how experienced or skilled a developer may be, the complexity of software systems ensures that bugs will emerge at some point. Rather than viewing bugs as obstacles, it's time to shift our perspective and acknowledge them as an integral part of the software development journey. Learning to accept and manage bugs is not a sign of weakness but a testament to the dynamic nature of programming. We wrote before about our philosophy of living with bugs in software that is already being used, today I’m going to delve into a more general view about dealing with bugs as part of the software development process - learning to live, accept and even learn from bugs that we create as we write code!

The Nature of Bugs

Bugs, also known as software defects or glitches, are unexpected behaviors or flaws in a program that prevents it from functioning as intended. They can range from minor inconveniences to critical issues that compromise the entire system. The diversity of bugs mirrors the complexity of the software itself, which is composed of countless lines of code, dependencies, and interactions.

Acceptance is the First Step

The first step towards writing great software is accepting the inevitability of bugs. Rather than viewing them as a failure, consider them as opportunities for improvement. Bugs are an inherent part of the creative and dynamic process of software development. Even the most renowned software products have their fair share of bugs. Understanding and embracing this reality is crucial for fostering a healthy mindset among developers.

“Industry Average: about 15 – 50 errors per 1000 lines of delivered code”

— Code Complete, Steve McConnell

In Steve McConnell's book, Code Complete, it is mentioned that the industry average for errors in delivered code is approximately 15 to 50 per 1000 lines. This metric is commonly referred to as defects per KLOC (1000 lines of code). McConnell further notes that Microsoft applications experience about 10 to 20 defects per 1000 lines of code during in-house testing and 0.5 defects per KLOC in production.

While achieving zero defects is possible, it comes at a considerable cost. NASA, for instance, achieved zero defects in the Space Shuttle Software, but the expense amounted to thousands of dollars per line of code. Such high costs are justifiable in situations where software bugs could lead to life-threatening consequences. However, for most projects, reaching the same level of testing rigor as NASA is financially challenging and often impractical.

Learning from Bugs

Bugs provide valuable insights into the intricacies of the software code. Each bug is an opportunity to learn, improve, and enhance the robustness of the system. By carefully analyzing bugs, developers gain a deeper understanding of the software architecture, identify weak points, and discover potential optimizations. The iterative process of fixing bugs contributes to the continuous refinement of the codebase. A great read is this article about strategies to handle defects in the agile methodology.

Here are some of the ways we can glean insights and improve from encountering bugs:

1. Root Cause Analysis: Investigate the bug thoroughly to identify its root cause. Understanding why the bug occurred is crucial for preventing similar issues in the future.

2. Knowledge Enhancement: Bugs often reveal gaps in understanding or knowledge. Use each bug as a chance to deepen your understanding of the programming language, framework, or tools being employed.

3. Code Review Practices: Regular code reviews can catch potential issues early in the development process. Analyze bugs to enhance code review practices and foster a culture of collaboration among team members.

4. Automated Testing Improvements: Enhance automated testing procedures to catch potential bugs before they reach production. Learning from bugs helps refine test cases and ensures better code coverage.

5. Documentation Enhancement: Document the bugs encountered, their resolutions, and the lessons learned. This serves as a knowledge repository for the team and aids in preventing similar issues in future projects.

6. Iterative Improvement: Embrace an iterative development approach. Use each bug fix as an opportunity to improve the overall codebase, making it more resilient and less prone to similar issues.

7. User Feedback Integration: Bugs reported by users provide valuable insights into real-world usage scenarios. Integrate user feedback into the development process to address issues that may not have been apparent during internal testing.

8. Continuous Learning Culture: Foster a culture of continuous learning within the development team. Encourage open communication about encountered bugs, solutions, and preventive measures.

9. Code Quality Metrics: Implement and monitor code quality metrics. Track the frequency and severity of bugs over time, and use this data to identify trends and areas that require additional attention.

10. Peer Collaboration: Facilitate collaboration among team members. Encourage open discussions about encountered bugs, and leverage collective knowledge and experience to devise effective solutions.

11. Adopt Best Practices: Incorporate industry best practices into the development process. Stay informed about advancements in coding standards, security practices, and technology trends to proactively address potential issues.

12. Incident Response Planning: Develop incident response plans to efficiently address and resolve bugs when they occur in a production environment. This minimizes downtime and ensures a swift recovery.

By approaching bugs as opportunities for improvement rather than setbacks, development teams can create a more robust and reliable software development process over time.

Effective Bug Management

While bugs are inevitable, effective bug management is essential for maintaining a high-quality software product. Over the years various processes and ideas have floated in the software development world for managing and reducing bugs. Six sigma management process is an example of such an idea of reducing bugs in a set software cycle. Agile methodology has definitely proven to be a very effective tool for managing and reducing bugs.

Here are some strategies to navigate the bug landscape:

1. Thorough Testing: Implement comprehensive testing practices, including unit tests, integration tests, and end-to-end tests, to catch bugs early in the development process.

2. Version Control: Utilize version control systems to track changes in the codebase. This allows for easy identification of when and where a bug was introduced, facilitating quicker resolution.

3. Bug Tracking Systems: Implement a robust bug tracking system to document and prioritize bugs. This ensures that the development team can systematically address and resolve issues.

4. Collaborative Development: Foster a collaborative development environment where team members can openly discuss and share insights about bugs. Collaboration accelerates the identification and resolution of issues.

5. Continuous Integration and Deployment (CI/CD): Automate the testing and deployment process to quickly detect and address bugs in the development pipeline.

In the ever-evolving landscape of software development, bugs are not adversaries to be defeated but companions on the journey toward improvement. Embracing the inevitability of bugs and adopting effective bug management practices are integral to writing great software. By viewing bugs as opportunities for growth and refinement, developers can transform challenges into stepping stones toward creating robust and reliable software systems. After all, in the world of programming, perfection is not the absence of bugs but the ability to navigate and overcome them with grace and skill.

I’ll end the post with a little comic we made in Bangla. The text translates roughly to - “Do you want write code without bugs? Then don’t even try!” This little comic sums it all up - you just can’t write code without bugs, you just have to learn to live with it to survive in this software development world.

Disagreements and debate: the crucial elements in great software projects

In the dynamic realm of software development, where agility and innovation are paramount, fostering an environment that encourages debates is not just beneficial—it's indispensable. The idea of debating within a software project may seem counterintuitive to some, as the conventional image of software development often revolves around quiet coding sessions and collaborative problem-solving. However, embracing debates in the development process can lead to a plethora of advantages, from refining ideas and uncovering hidden issues to enhancing team collaboration and achieving superior project outcomes.

Innovation through Divergent Perspectives

One of the primary reasons debates are crucial in software projects is their ability to stimulate innovation. Divergent perspectives, often emerging during heated debates, can catalyze the generation of creative solutions to complex problems. When team members bring unique experiences, insights, and approaches to the table, it opens up avenues for exploring unconventional ideas that could be game-changers. This realization has led to many software leaders actively seeking a diverse software dev team in the hope of inserting divergence in perspectives in team decisions.

Debates force individuals to articulate their thoughts, challenge assumptions, and present evidence in support of their ideas. This process of intellectual rigor helps in refining concepts and ensuring that the final solutions are well-thought-out and robust. Without debates, a team risks falling into the trap of groupthink, where conformity stifles innovation and unconventional ideas are overlooked.

Identification and Mitigation of Risks

Software projects are rife with challenges, and potential risks can lurk beneath the surface. Debates serve as a powerful mechanism for surfacing these risks and addressing them proactively. When team members engage in discussions about project requirements, design choices, or implementation strategies, they are more likely to identify potential pitfalls that might be overlooked in the absence of scrutiny.

By thoroughly debating different aspects of a project, ranging from technical decisions to project timelines, the team can anticipate and mitigate risks early in the development process. This proactive risk management is crucial for ensuring project success and preventing costly errors down the line.

Enhanced Collaboration and Team Dynamics

Debates, when conducted in a constructive manner, contribute to a positive team culture by fostering open communication and collaboration. When team members feel empowered to voice their opinions, it promotes a sense of ownership and engagement. Additionally, debates encourage active listening, as team members must understand and respond to each other's arguments.

Moreover, healthy debates provide an opportunity for team members to learn from one another. As individuals share their knowledge and experiences, it creates a collaborative learning environment where everyone can benefit from the collective wisdom of the team. This learning dynamic not only improves the skill set of individual team members but also contributes to the overall growth and development of the team as a whole. One thing important in this area is the leadership style of the team leads in the software project. If the style of leadership is not open to a multitude of ideas then the benefit of enhanced collaboration breaks down and the debates turn into points of division within the team.

Refinement of Ideas and Decision-Making

In the crucible of debate, ideas are refined, and decisions are thoroughly scrutinized. This process is essential for ensuring that the chosen path is the most effective and well-considered one. Debates force individuals to defend their proposals, encouraging a deeper understanding of the implications and trade-offs associated with different choices.

Through this rigorous examination of ideas, the team can make informed decisions that are more likely to stand up to the challenges of implementation. The act of defending one's position in a debate requires a comprehensive understanding of the subject matter, promoting a culture of informed decision-making within the team.

Continuous Improvement and Adaptability

Debates are not static events but dynamic processes that unfold as projects evolve. In the ever-changing landscape of software development, the ability to adapt and iterate is crucial. Debates contribute to a culture of continuous improvement by encouraging teams to revisit decisions, reassess strategies, and incorporate new insights and information as they emerge.

This adaptability is particularly important in agile development environments, where the ability to respond quickly to changing requirements is a key success factor. Embracing debates as a means of continuous improvement ensures that software projects remain agile, resilient, and capable of delivering value even in the face of evolving challenges.

In the fast-paced world of software development, where the only constant is change, the importance of debates cannot be overstated. By fostering innovation, identifying and mitigating risks, enhancing collaboration, refining ideas, and promoting adaptability, debates play a pivotal role in shaping the success of software projects. Teams that actively engage in constructive debates are better positioned to navigate the complexities of development, resulting in superior outcomes and a culture of continuous improvement. In the vibrant ecosystem of software projects, debates are not just discussions—they are catalysts for excellence. We have a joke at Kaz that if only two people agree in a group of many we have a decision! The little comic here says that in Bangla :)

Strategies to Avoid Analysis Paralysis in Software Development

Embarking on the profound journey of software development, one is quickly confronted with an elemental truth: there is no singular answer to any problem. This revelation, cultivated over years spent traversing the intricate landscape of algorithms, architectures, and enterprise platforms, is a foundational tenet of a seasoned software practitioner's wisdom. In this exploration, we delve into an extensive array of strategies, tips, and insights accumulated over decades to avoid the notorious pitfall known as "Analysis Paralysis"—a condition that has the potential to stifle innovation and progress within the realm of software development.

Analysis paralysis (or paralysis by analysis) describes an individual or group process where overanalyzing or overthinking a situation can cause forward motion or decision-making to become "paralyzed"…

Diverse Solutions, Diverse Perspectives: The Essence of Software Problem-Solving

The very essence of software problem-solving lies in the acknowledgment of the myriad ways one can arrive at a solution. Whether grappling with the intricacies of a simple algorithm or sculpting the blueprint for a sophisticated enterprise platform, every problem unfolds a cornucopia of potential solutions, each laden with its unique set of advantages and drawbacks. The challenge transcends merely finding "A Solution"; it involves navigating through the labyrinth of alternatives without succumbing to the pitfalls of perpetual analysis. The software development landscape is, at times, besieged by the affliction known as "Analysis Paralysis," wherein teams become ensnared in the web of alternatives, often resulting in indecision or, worse, a protracted stalemate leading to time depletion.

Ego: The Silent Saboteur in Software Development

The cardinal rule that stands as a beacon amid the complexities of software development is the imperative to divorce personal ego from professional discussions. Ego, oftentimes the silent saboteur, emerges as the biggest impediment to progress. The ability to detach oneself from ideas becomes a hallmark of seasoned developers. It is not about defending one's ego; it is about finding solutions. The moment discussions devolve into personal defenses, the focus shifts from the noble pursuit of creating value to the counterproductive endeavor of preserving one's ego—an unfruitful detour that hampers collaborative innovation. We are big fans of Ryan Holiday’s book about Ego - Ego is the Enemy

We are such big fans of the book that we have also made a video about it our books that software developers must read series in Bangla.

Standing on the Shoulders of Giants: Leverage Collective Knowledge

Design Patterns: Elements of Reusable Object-Oriented Software

By Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

In a domain where problems often recur, acknowledging that others may have already navigated similar challenges is paramount. Leveraging the vast repository of knowledge available online, particularly through platforms like Stack Overflow, becomes a strategic imperative. The power of authoritative voices cannot be overstated; quoting industry giants and referencing proven design patterns can elevate a discussion from a mere exchange of opinions to a collaborative pursuit of well-founded solutions.

"In my view, the Gang of Four is the best book ever written on object-oriented design - possibly of any style of design." — Martin Fowler

The Power of Data: Informed Decision-Making in Software Development

Data, the bedrock of informed decision-making, is abundantly available in the software domain. Harnessing statistical data, survey results, and insights from scientific studies can provide concrete support for proposed solutions. From the impact of developers' seating positions to broader topics like software architecture, relying on reputable data sources becomes instrumental in guiding teams out of the quagmire of analysis paralysis. It transforms decision-making from subjective deliberations to an objective process grounded in empirical evidence.

The Personal Touch: Sharing Experiences as a Catalyst for Understanding

While data adds an objective weight to arguments, the personal touch of shared experiences provides a relatable dimension. Narratives from one's own journey, divested of ego and fortified by precise connections to the current context, can resonate profoundly with the team. Anecdotes become powerful tools when used to illustrate how past experiences align with proposed solutions, fostering a deeper understanding and connection among team members.

Embracing Open-mindedness: The Antidote to Rigidity

Acknowledging the absence of a perfect solution is not a concession but a realization of the dynamic nature of software development. No team can claim perfection, and staying open-minded becomes the linchpin for continuous improvement. An agile approach, marked by skepticism and a readiness to reassess decisions, helps navigate the ever-evolving landscape of software development. The ability to pivot and adapt, even after reaching a conclusion, ensures that teams remain agile and responsive to the multifaceted challenges that arise.

Testing the Waters: Prototyping, A/B Testing, and Surveys

In a realm where certainty is elusive, keeping options flexible is paramount. Teams can employ various strategies to test proposed solutions and mitigate the risk of committing to an unsuitable path:

Prototyping

Creating a low-cost prototype can be instrumental in testing specific functionalities or validating the feasibility of an approach. A quick test project has the potential to provide tangible insights, resolving potential bottlenecks before they become significant obstacles.

A/B Testing

If possible, running low-cost A/B testing can shed light on which of multiple solutions is a better option. By pitting two opposing groups against each other, teams can design low-cost tests to prove or disprove the effectiveness of different approaches.

Surveys

Engaging stakeholders, including customers or other software developers, through surveys can provide valuable external perspectives. Asking for opinions on proposed solutions or seeking feedback on the perceived technical viability can augment the decision-making process.

In the dynamic realm of software development, the ability to navigate through the multitude of solutions is an art. Freeing oneself from the shackles of ego, leveraging authoritative voices, relying on data, sharing experiences, and embracing open-mindedness collectively form a robust toolkit for steering clear of analysis paralysis.

As we continue to evolve in the world of coding, these strategies serve as a compass, guiding us through the maze of possibilities. In the end, it's not just about finding a solution but about embarking on a journey where every road taken contributes to the collective wisdom of the software development community. The software development odyssey is a continuous exploration, where adaptability, collaboration, and a commitment to learning become the sails propelling us forward into the uncharted waters of innovation and excellence.

Managing a multi-cultural remote software team

Remote work is the new normal, and managers need to be prepared to lead their teams in this new environment. And in today's globalized world, multicultural teams are the common remote teams. Cultural diversity is common in onsite teams too but the issues of miscommunications because of cultural issues are much more complex in remote teams. With the rise of remote work and the desire for flexibility among younger generations, managing a team from different cultural backgrounds has become one of the biggest challenge for managers. And this is an essential skill that all managers are picking up.

Since Kaz is a software development agency based out of Bangladesh and we work mostly with software companies based in the US or Europe. So the very nature of our work leads us to the remote cross cultural issues. And this not a new thing for us because of the recent rise of remote work. We’ve been participating in remote software teams for the past 18 years, and over that long time we’ve probably seen all the things that can go wrong in such cross culture, cross language teams and have devised strategies that solve those issue (or at least reduces to chances of them arising). We’ve also come up with a little poster for expressions in English that doesn’t translate well, that we sometimes give to our customers’ project managers as a cheat-sheet! So, today’s post is a summary of some of our best tips around this and that useful “cross culture expressions to avoid cheat-sheet”.

Understand that there is problem

This is important. Specially in the software world. We sometimes hear things like: “At the end it’s all code, and the language of code is the same so there will be no problem”. Although at the fundamental level that is very true, but to get to that stage of work and collaboration the remote teams still have go through layers of communications. That communications is typically in a language that isn’t a first language for at least one side and sometimes for both sides. And that’s where the start of the problem happens, and layer on top of that the cultural difference and the fact that cultural context changes the meaning of many expressions and mannerisms - you have a problem. So it’s vital for software managers to understand that there is a problem and it will need active strategies and process to solve that problem.

In this context, it is essential to recognize that cultural differences can lead to misunderstandings and conflicts. As the speaker in the video explains, even seemingly simple things like expressions about time can have very different meanings in different cultures. For example, in some cultures, "just now" might mean "in a few minutes," while in others, it might mean "sometime in the future." Without understanding these differences, miscommunications can easily arise, leading to frustration and conflict.

Create culture awareness in the team

To address this challenge of cultural difference and the need to work around such difference, it is important to invest in cultural awareness and sensitivity training for managers and employees. This might involve providing resources such as books or online courses on cross-cultural communication, as the speaker in the video did. It might also involve hosting workshops or training sessions led by experts in intercultural communication.

One key aspect of this training should be the importance of context in communication. As the speaker explains, even when two teams are using the same language, differences in context can lead to misunderstandings. For example, a phrase that might be intended as a compliment in one culture might be interpreted as criticism in another culture. Understanding these differences requires a deep appreciation for the cultural norms and values that shape communication styles in different parts of the world.

Create an environment of trust

Another important aspect of managing a multicultural team is building trust and rapport among team members. When people come from different cultures, they may have different expectations about how to build relationships and establish trust. For example, in some cultures, it may be important to spend time getting to know someone on a personal level before discussing business matters, while in others, business may be the focus from the outset. Understanding these differences can help managers to build stronger relationships with team members and foster a sense of camaraderie and trust.

We’ve written extensively about this in the past, as we feel that this is one that that makes thing much simpler to solve cross cultural issues. Some of our tips can be found in this article about how to build trust in your remote team by team gelling or this one about creating the right team culture for companies with remote teams.

Find what works the best for you

It is important to recognize that managing a multicultural team is not a one-size-fits-all endeavor. Different cultures have different expectations around communication, hierarchy, and decision-making, among other things. Effective managers must be able to adapt to these differences and find ways to accommodate the needs and preferences of each team member. This might involve using different communication tools for different team members, or adjusting work schedules to accommodate different time zones.

Careful about what expressions you use

It's important to be aware that expressions that you might use in your language or cultural context might not be understood at all or even worse understood with the opposite meaning by your remote team. It is vital for team managers (and team members) to consider cultural differences when communicating with people from other backgrounds. It's also a good idea to clarify the meaning of an expression if you think it may be misunderstood. Here’s our list of common English expressions that just doesn’t cross the language and culture basriers well. We call it the expressions to avoid cheat-sheet!

"Break a leg" - This one never works. In most non-English cultures, wishing someone luck by saying "break a leg" is considered bad luck or even offensive. Actually if you think about it really weird that this expression has the meaning it has, here’s the Wikipedia post giving it’s history.

"Bite the bullet" - This expression means to endure a painful or difficult situation, but in some cultures, the literal meaning of biting a bullet can be confusing or offensive.

"Spill the beans" - This expression means to reveal a secret, but in some cultures, the idea of spilling beans may not make sense or may be seen as wasteful. I remember once one of our customers used this expression in the context of asking his team not to reveal software features anyone and the look of confusion in the team was very interesting!

"Piece of cake" - This expression means that something is easy, but it almost always fails to translate well.

"Going Dutch" - This expression means to split the bill, but in some cultures, the idea of going Dutch may be unfamiliar or seen as impolite.

"Skeletons in the closet" - This expression means to have secrets or embarrassing information, but to someone not used to the expression the idea of keeping skeletons in a closet would not make sense at all!

"Costs an arm and a leg" - This expression means that something is very expensive, but in some cultures, the idea of comparing something to body parts may be seen as distasteful.

"Cat got your tongue?" - This expression means to ask someone why they are not speaking or responding, but this one never works either for obvious reasons.

"Let the cat out of the bag" - This expression means to reveal a secret, but the idea of a cat being in a bag may not make sense or may be seen as cruel for non English speakers.

How to motivate a remote team

Remote work is now the norm. This is one thing that the COVID has pushed us to and has proven that it works. Companies that never did remote work (including us at Kaz) are now fully functional and thriving with remote work. And remote work is here to stay as a work model - it’s very likely that every company in the world (including us) would keep some form of remote work in their process. Everything has a downside - and for remote work it’s the lack of the rest the team near you that starts having an effect. Over longer period of time motivation for work becomes a big stumbling block. And for manager and team leads it’s not an easy problem to solve. But we’ve found that it’s not an impossible problem either.

“77% of remote employees say they’re more productive when working from home”

— Survey by CoSo Cloud

You don't have to be next to someone's desk in order to feel the energy of a team that can work together and accomplish goals. As a manager, you can motivate and inspire your remote team just as well as you would if they were all sitting in your office.

Here are our top tips for motivating your team remotely.

1. Set clear expectations for your team

We are used to taking visual ques from all our interactions, these ques form much of our understanding in any conversation. A remote team misses a lot of these visual ques in an interaction over a zoom call or worse over an audio only call. So it's vitally important that common understanding of expectations is reached. We tell all our customers to set aside a slot at the end of every meeting to just go over the main points of the meeting and check that the both sides agree on what the expectations are.

2. Be transparent about what is happening

When your remote team feels out of the loop, they are less likely to want to engage. People are motivated by being informed about what is going on around them, so tell them! If they miss something, feel free to say "let me go over that thing" or "you should hear about a new development that is happening". This is especially true for software teams, as software development is typically a very collaborative effort and if the remote team feels that they are left out of decisions, changes in requirements etc. it will create a loss of motivation and just make the overall process of software development difficult.

3. Communicate regularly

The remote work experience will be a lot better if there are regular communication channels between the remote team and the office. Some ways to keep them in the loop is by having weekly meetings that are open to all members of the remote team, sending out emails with important updates on new features or scheduled changes, etc. Asking them regularly how they are doing, where they are on particular tasks or deliveries.

There are many other ways you can motivate your remote team. Some of them are time off or bonuses, but at the end it is about working with people who enjoy what they do - And if they are happy to work for you, you will get an effort that goes beyond the job requirements.

For small companies this might seem like a lot of overhead, but it is vitally important for the longer term.

“2020 has seen a 9% increase in Google search interest related to “team-building””

— www.thinkwithgoogle.com

How to make a software project plan that actually works

Making a project plan for software development is one thing, but making it work is another. You've probably seen lots of software project plans in your day. They all look the same with their pretty Gantt charts and lovely blue annotations, don't they? Yet, do you know the failure rate of these pretty Gantt charts? That number is an unbelievable 78% according to one study in 2009 (the same group found a failure of 84% in IT projects in 1994!). This humongous failure number keeps coming up in studies after studies, here’s one by another very respected group - McKinsey-Oxford study for IT projects

Given these huge failure numbers we have to accept the reality of difficulty of making a software project plan that works. Over the years we at Kaz Software have worked on numerous software projects, for hundreds of companies around the world and we know from first hand experience how difficult this is. There are hundreds of variables that you should be thinking of when making a reliable project plan - from obvious ones like requirements, business priorities, resource availability to unexpected ones like language barriers, paperwork, compliance issue, etc. On today’s post I’d like to share some of the things we have learnt about making a better project plan - not perfect, maybe perfection isn’t possible, but a better one at least!

Decide on a project timeline and set deadlines

The first step is to decide how long your project will take. One month, three months, six months? Or maybe you can't put an exact number on it because you aren't yet sure what the project entails. That's fine too - just be as accurate as you can. The point is to be realistic, to have all the information available at that point in time and make the best possible guesses based on that information. If you know the requirements will change frequently, set deadlines for each round of revisions. If you think your team members are bad at estimating their time, maybe give yourselves a longer timeframe. Set deadlines that are achievable but challenging. Don't be too optimistic or you'll end up disappointing yourself and everyone around you when things don't go as planned.

Create a list of tasks with a democratic estimation

This is where you break down the requirements into smaller areas, features and then eventually tasks. Make sure you about break large, vague tasks into smaller tasks with deadlines that are based on the time estimates. Breaking down the larger tasks into smaller tasks are relatively easy, especially if you have experienced resources in your team. Where it gets extremely hard is the time estimation of tasks. Most developers will either overestimate or underestimate time cost for a task. This is just a fact of life. Our solution has always been to use democracy to find the time cost number - effectively asking all members of the team to discuss and come up with a time estimate rather than relying on a single person (the developer who is likely to do the task). This may sound counter productive, as the task will be done by a single developer at the end of the day - but somehow the democratization of this process gives much better result.

“Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.”

— Joel Spolsky

On this point I’d like to note another very effective way of getting time estimates - which is to look at historical success and failure rates of estimates per developer and based on that decide if the developer typically over or under estimates and then add or subtract based on that data. This idea was very effectively put into use in Joel’s FogBugz product - and he called it evidence based scheduling. You do need a platform like FogBugz to make this happen, and even then you need to have enough historical data with the same developers to make it really work.

Write down the resources needed for each task

This is where you list who's expertise is required to complete each task and what kind of equipment will be used. If the skills required for a task is not available in your team, plan for it - how you will fill up the gap, what steps you'll need to take to have that skill available at the right time. Some of those steps may be tasks themselves that you have to add to your project plan.

Set up milestones that you'll need to meet

Milestones let you know how much progress you've made and if everything is on track with your timeline. You can set up intermediate deadlines as well if you're not afraid of breaking your work into smaller chunks. If you have a long term project, it may be better to set up milestones at the beginning so that you'll know how much you can do every week or every month.

Make sure your plan is achievable by breaking it into small enough chunks so that you can achieve them one by one. Divide and conquer is the the only way to solve the complex problems in a software project. If you decide to take on something big, it can quickly become overwhelming. Try breaking your project into smaller pieces and figure out how long each one should take.

Stick with it!

Don't give up when things get tough! You're almost there! This is the most important tip of them all. If you have failures, delays, setbacks just know that that is a fact of life for all software projects. You just have to have the patience to stay with your plan, make changes as needed to adapt to the delays and move things forward. Software projects never go as planned, and one of the greatest sign of a good plan is that it has the ability to absorb the changes as they happen. And the one most important skill of a software leader is the the ability to stick with the plan.

Remember that a software project is a process, and it can be thought of as a linear progression from one phase to the next. Plan out how you will go from start to finish with milestones in between. Use your resources effectively by having the right people on the job for specific tasks, making sure you have access to special equipment or resources.

Let’s break these horrible failure stats. Good luck!

10000 hours of practice - fact or fiction?

It all started when Malcolm Gladwell published yet another one of his blockbuster books - Outliers. One of the ideas in the book was put in enough practice and anyone can be an expert of anything. In the book, Gladwell states that:

“ten thousand hours is the magic number of greatness”.

Outliers is one of those books that really motivates you, and this idea that you don’t have to be a born genius to become a good at anything is one it’s biggest uplifting moments. Gladwell quotes several studies and gives examples like starting really early and getting those 10,000 hours of practice made the Beatles become the greatest band in history. For example, between August 1960 and December 1962, the they played over 250 all night shows in Hamburg, playing four to five hours a night. This racked up their practice numbers, Gladwell argues, refining their skills leading to becoming the best. John Lennon him self is quoted as saying “In Hamburg we had to play for hours and hours on end,” he said. “Every song lasted 20 minutes and had 20 solos in it. … That’s what improved the playing.”

Is it a fact?

But is this true? Does putting in 10,000 hours into anything makes you the expert? Specifically, for us software people, we can ask “can anyone become a top developer by putting in 10K hours of programming?” Well for a start we all know that the more you code the more you become good at it. It’s one of the first advice we give to freshers or students when they ask about career improvement. There is absolutely no doubt practice makes a man perfect in the coding world. But the bigger question is, can anyone without any coding experience jump in and put in those 10K hours and become the best? This is where you’ll see a lot of dispute. In our experience, some people just are good at logic, or at looking at new ways of solving a problem, or thinking out of the box to find amazing way outs from knotty technical issues. If you start with one of those people and push in the 10K, yes for sure you’ll end up with a world class software developer. But if you start with someone who is not good at logic or just has a different way of thinking that get him into complexity all the time, I fear the 10K will not work so well. So I guess my answer is:

“it depends”.

This “it depends” seems to be in other fields too where the 10K rule is getting debunked. The original science behind the 10K rule was the 1993 paper by Ericsson et al. : The role of deliberate practice in the acquisition of expert performance that studied violinists and their achievements. But a recent study done to check those results found gaps and also the fact that beyond a certain level of achievement other factors came in to make the role of practice less clear.

10K hours of coding?

Let’s say that the 10K rule is a fact. Is it something we can actually do and become the greatest coder around? How long would it take? Let’s do some quick maths

If you wanted 10K hours of coding in 1 years you’d have to do 27 hours a day. So that’s impossible (unless you start approaching light speed and time dilates a bit for you).

If you wanted to do it in 5 years, you’d need to code 5.4 hours a day, 7 days a week. Kind of do-able if you want to loose all your social life. I actually know about someone who did/does something like that. He is definitely one of the best coders in his area, but has lost most of his life and family to the art of coding… so not sure if that was such a good move.

If you wanted to do it in 10 years, you’d be coding 2-3 hours a day, 7 days a week… now this is entirely possible and should be the recipe to make it big in the coding world.

So fact or fiction, coding 10K will improve your skills from where ever you start. Aiming for a reasonable 10 year plan with coding hours fitted in there almost everyday is something every aspiring coder should plan for. And read the book, btw, we are going to do a quick book summary soon about it!

Deep Work - Great book for software professionals

It was a nice winter day at Balmoral hotel. The writer of Harry Potter series J.K. Rowling left a signed statement on a marble bust of Hermes in her room which read: “J.K. Rowling finished writing Harry Potter and The Deathly Hollows in this room (552) on 11 January 2007.

Yes, you have read it right. J.K. Rowling wrote the final book of Harry Potter series in a hotel. Because, she needed undistracted concentration to produce a world class work. Not only her, but also Bill Gates did require such uninterrupted attention to complete the first version of “basic” in 1974 which laid the foundation of a billion dollar company “microsoft”.  He used to close himself up in a separate room most of the time for 8 weeks to produce such a program. Mark Twin, Rabindranath Tagore and so on also had similar patterns. So, what were they actually doing! What is it called?

Deep Work by Cal Newport 

Deep Work: Rules for Focused Success in a Distracted World

By Newport, Cal

Author Cal Newport, an MIT graduate and Georgetown professor has named this as “deep work” and explained this phenomenon in his book “deep work”. He also claimed that, this deep work helped him to double the output of his research papers while raising a family, writing the book and teaching fulltime in a prestigious university.

Now, you might think that, they were some extreme examples or privileged people to do so. But the author shows us some way of how we can manage to do deep word despite busy or daily schedules of other works. Before this, you should know why we need deep work because we all don’t want to be Bill Gates or J.K. Rowling.

According to the author only 3 types of people are going to be successful in the upcoming tight economy.

• People who have large capitals to invest in companies

• People who are very good at technologies

• People who are very good at what they do

 For most of us, the first two are usually not possible, but we all can manage to attain the third quality. That’s where deep work becomes significant. Neuroscientists have found that intense level of focus in isolated fields of work caused “myelin” to develop in relevant areas of the brain. Myelin is a white tissue that develops around our neurons  and allows brain cells to fire faster and cleaner. So in a sense, when we practice deep work, we upgrade our brains and allow specific brain circuits to fire more effortlessly and effectively. It also allows us to rapidly connect ideas and uncover creative solutions. It helps us to produce something standout amongst the noise and avoid being forgotten by the flood of information that we deal on a daily basis.

Shallow work vs deep work

Shallow work are such works that allows distractions like talking to colleague, listening to music, replying texts etc. We also call them multitasking. It decreases our productivity and wastes our time. Whereas, deep work is totally the opposite. Deep work increases our thinking capacity and increases concentration that boosts productivity and makes our work hard to replicate. The shallow work that we do today will be replaced by automation in near future and more people will be willing to do it in lesser payment since that’s easy to do with other tasks.

Attention Residue

Suppose, you are writing a novel with 100% attention. Suddenly, the phone beeps and you reply your friend. Then when you come back to the novel, you can come back with 70/80% of your attention. Rest of the attention stays with your phone. The more you multitask or get distracted, the more you lose your attention to the particular task and in the end, you can’t give your 100% which leads to an average output.

Four methods of deep work

Monastic deep work

Here, we completely separate ourselves from the daily or distracting environment and focus on our work. We have to isolate ourselves from the world until our goal is achieved.

Bimodal deep work

Here, we can conduct deep work for a particular period and live our usual life for the rest of the time. For example- J.K. Rowling used to separate herself into a hotel and for writing all day long and by the evening she used to join the regular world.

Rhythmic deep work

Here, we can fix a particular period (couple of hours) for deep work such as morning of the day to work without distraction and do our rest of the works at a regular basis.

Journalistic deep work

Here, people who are very busy with their schedule, can prepare themselves in such a way that whenever they get free time, they use it for deep work. Peter Shankman can be a great example for that: the author needed some distraction free isolated environment in his very busy schedule to write a manuscript for his book, he bought a round plane trip business ticket from USA to Tokyo. He got 30 hours without distraction in the air to complete his work. Here, he paid some expense but the output that he got, outweighed the expense.

We also need proper food and sleep for the brain to keep focusing on our work. Deep work requires serious will and patience to accomplish. And the result is always something special. So, if we want to be successful in this modern world where unemployment and overpopulation will take over the job sectors, deep work can lead us to the way of success and make you the best version of yourself at your work.

Here’s a quick book summary in Bangla…

Atomic Habits - Great book for software professionals

We are starting a new series on great books for software professionals. The plan is to find books that help us become better professionals in the software development field. We plan to cover both technical books like programming, architecture, etc. and also non technical books that help with our people skills, improve motivation, that help us manage work and life better.

We start this series with one our favorite self help book - Atomic Habits by James Clear. A book that is for everyone. It shows in very simple and clear language with actionable steps how making small changes in our life leads to amazing improvements overall. This is a perfect book for software professionals as they deal with a huge amount of complexity in their work for which they have to constantly learn new things, manage their time better to improve and hone their skills. We’ve benefitted a lot from it and hope you will too.

Summary

Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones

By James Clear

When we want to achieve a goal, what do we do? We set the goal and work for it. But is that enough or does that truly lead to the goal that we want to achieve!

Here comes the big question, what does it take to truly achieve the goal? The simple answer is process. But when we hear about the process, we think of a long boring stuff that requires patience and persistence. So, is it really that tough?

What makes the difference between the winners and losers is action. When we set a goal and do nothing but watch the time passing by, in the long run become losers. On the other hand, who follow the system, make continuous small improvements, actually achieve the goal. Just like any particle is made of small atoms, remarkable results are also made of atomic habits. Habits that make the real difference. So, if we want to achieve it, we have to forget the goal and follow the system instead.

Changing Habits

Generally, habits can be changed in two ways- outcome based and identity based. Let’s draw a very practical example that can help us.
Suppose, someone wants to quit smoking, now if he is asked to smoke, he can possibly give this answer “Sorry, I am trying to quit smoking”. Now, let’s be honest, we all know it doesn’t help much. Here, the person is trying to improve but is not ready to change his identity. And this makes it harder for him to fight against the person who he thinks he is.

WHAT IF ….

He put a different answer instead? Like, “Sorry, I’m not a smoker”.

Anything that we do repeatedly, becomes our identity. Our every action votes for the person we want to be. Because no single action can change our identity. Rather the repeatability of that action can change our identity. When we confidently talk to someone, our identity as a public speaker gets recognized; when we influence others, our identity as leader gets recognized.  Hence, first we have to decide, what type of person we want to be and according to that, we have to keep voting on that identity. If you want to be a gentleman, then your behavior on the road, bus, train should be accordingly. Because we are changing our identity with our belief system.

Four actions

Our habits are generated through the following four steps-

·         Cue

·         Craving

·         Response

·         Reward

Cue is what reminds us of the reward. Craving pushes us towards get the reward and our response makes us to achieve the reward. And we want the reward because we will either have satisfaction from it or we can learn something. And if anything is insufficient among these 4 steps, changing any habit won’t be possible properly.

From these 4 steps, we can say that, we can follow 4 steps to build a book reading habit- 

• Cue: This should be highly visible. If the books are visible, then we can easily notice that, yes, I have to read books.

• Craving: Here we have to make the visibility attractive. For example- we can add bookmarks on the book so that we can easily know how much we have and where we had left.

• Response: This should be easy to respond. So that, it doesn’t become hard for me to reach them.

• Reward: Here we can choose the right book. So that, it brings a higher level of satisfaction for us.

Ways to remove bad habits-

·         Cue should be invisible

·         Craving should be unattractive

·         Response should be difficult

·         Reward should be unsatisfying

We can apply these 4 steps to remove any addiction like- smartphone addiction.

We usually imitate our habits from these three groups of people

The close, the many, the powerful. We are inspired by these three groups in general. Some people think that, they lack motivation. But actually, they lack clarity. They actually don’t know how to start things and how to proceed them. In real- environment is more important than motivation. For example- in case of buying a product, the things that are placed in front of a store, we tend to try them in the first place. So, in case of building a habit or leaving it, we have to setup proper environment for that.

People think that, self-controlled people are driven by their willpower and self-discipline. But actually they design their life in such a way that in order to be disciplined, they don’t need much of discipline. For example- if they think television is killing their time, then they will remove the television from their house.

And when we try to build a habit, we have to keep tracking that process that we are following and try to measure that progress.

To sum it up

We have to remember that, our brain loves challenges. That doesn’t mean it will like challenges that we can never achieve. For example- I love to play tennis. Now if I am put against Roger Federer, then very soon I will lose all my enthusiasm. And if I start to play against a little kid then I will get bored. So, the challenges should not be bored or overly challenging.

Atomic habits are the key to a massive change. So, rather than daydreaming, we have to develop a process and act on it.

Here’s a quick book review in Bangla…

Data privacy regulations 101

Data privacy is obviously very important. With large companies gather huge amount of data of it’s users and with the great advancement on data mining and data analytics technologies data privacy has become one of the biggest concerns for all consumers. If you are not that concerned about this, you should be, here’s a quick read to get your concern raised - a quick survey of what data FB or google already has about you.

This concern is reflected by the various regulatory bodies and governments stepping up their regulations about what companies can do with the data, how they can share it and how they have protect it.

The problem is that the online world has not autocracy! And in those rare cases in this world where autocracies are great this is one place all software creators wish there was one single autocratic power giving out a single set of rules to abide by :) Sadly that’s not the case and a software developer that wants to serve customers around the world (i.e. every software company in the world) now has to understand a plethora of data privacy rules and regulations, create interfaces for seeking consent, show text for displaying warnings, create processes for managing the security and the privacy. This is why every website we visit today has a confusing range of popups, highlights, texts, footers and headers asking us to accept this or decline that or warn us that we will lose our soul if we don’t do this or that. In general, all this chaos has just created a fatigue in the consumers who just click accept where ever they see it just to get to the page. But that is another story.

Today’s post is for the software developers and software founders who wants to get a quick overview of where things stand now and how to navigate in this jungle.

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) is a Privacy, Security, and Breach Notification Rules protect the privacy and security of health information and provide individuals with certain rights to their health information.

If your software has anything to do with healthcare, medical services even pharmaceuticals and drugs you should be concerned about HIPPA compliance. It’s a US standard but complying with this basically ensures that you comply with any of the national rules you are likely to encounter in other countries.

Software developers play a vital role in protecting the privacy and security of patient information that comes in through thousands of software systems and interfaces in an increasingly digitalized healthcare world.

At its core HIPAA is pretty simple and based on the following 3 parts:

• Privacy

  This deals with protection, authorization and access. It sets rules for when and how any personal health information can be disclosed and used. It also gives users the ownership of their health records, the right to access them and request modifications as needed.

  So any system you develop needs to have the flexibility and security built on top of the data store.

• Security

  This is the obvious section on the standards for the security of technology used to access, store, transmit, or process any personal health information. This part is the big thing that you as the software developer need to focus on. Certain implementation specifications are either required, meaning that its mandatory to build them in your software, and some are addressable. Addressable are ones in which either you need to 1) implement the specifics as written, OR 2) implement an alternative solution, OR 3) not implement anything for that specific requirements because it is not reasonable or necessary to do so. As with most things in HIPAA, the important thing is that decisions related to addressable specifications are documented.

• Simplified Process

  This part relates to the accepted coding for data exchanged in healthcare. The transactions this applies to are financial related (claims, eligibility, enrollment, etc). To comply with this part you have to make it administratively easier to exchange data by not having to keep track of an endless number of code sets. (What’s a code set?)

GLBA

The Gramm-Leach-Bliley Act (GLBA) is a US law for control on personal financial data managed by financial institutions, and how these institutions deal with a consumer’s non-public personal information (NPI). There is a lot of very private personal financial data that organizations like banks, insurance companies etc. collect when providing a financial product or service and GLBA is the overarching rule that gives users protection on the use of that data.

If you have anything to do with a fintech app or any platform that is used by a bank or an insurance company it’s very likely you’d need to know about GLBA and comply with the it’s guidance.

From a bird’s eye level GLBA has three main parts:

• Privacy Rule

  This regulates the collection and use of NPI. This is the part you as the software developer need to focus the most. It’s pretty comprehensive and there are lots and lots of issues that you have address in this area - so you’ll need to spend time in getting to know the rules. Wikipedia article on the privacy rule does a good job in getting you a quick background.

• The Safeguards Rule

  This part requires financial institutions to implement a security program to protect NPI. So this more on the side of the institutions and their network but doesn’t stop just at physical security so intelligent monitoring of data and transactions is something software developers will probably need to integrate with other solutions within the infrastructure.

• Pretexting provisions

  This prohibits access to NPI under false pretense and is more of a legal concern for the organization and it’s workflow processes. As a software developer you will need to ensure access control and several layers of authorization and monitoring of access.

COPPA

Children's Online Privacy Protection Act (COPPA) is a set of rules that prohibits online software such as websites, apps and games from collecting personal information from children without first providing notice to parents and obtaining their consent. The rule also provides parents with the right to find out about stored data collected from or about their children, and to refuse further data collection and use.

If you are building any software that is primarily directed towards children then you need to be aware about COPPA. Although a US rule it is a rule that was used by most national rules to create their own children protection acts. COPPA is super important for game developers particularly for mobile games - as any failure may lead to a permanent ban from platforms such as apple appstore or google play. Here’s a great primar for game developers

If you didn’t know the story, a recent example where COPPA non compliance led to a big fine was Tiktok, which was fined $5,700,000 in February 2020

Here’s a bird’s eye view of different parts of COPPA you need to be aware of:

• Privacy Policy

  You need a clear and detailed privacy policy and it must be linked clearly on highly visible location within your application, especially where personal information is collected. The privacy policy need to include all information you collect from children, details about how such which the information is used, and whether it is shared with any third parties. You must also reveal the names and addresses of the owners of the software so that may be contacted by parents.

• Parent Opt in

  You need to provide parents of the child user with a message and obtain their consent before using personal information of their child. You need to tell parents that you collected information about their children, describe the information, explain what manner it may be disclosed, and that parental consent is required to do so, and also provide a link to your privacy policy, provide a way to give consent, and let them know you will delete their information if you do not receive their consent.

• Disclosure to Third Parties

  If any information collected by the software will be disclosed to others, you will need to provide a stronger method for consent, such as a signed form, or a contact number. After giving consent, parents must have access to the data for reviewing and deleting their child’s information.

SOX

Sarbanes-Oxley Act (SOX) is a set of regulations that sets the compliance needs and deadlines for public companies. SOX came out necessity when corporate America was broiled with scandals from giants like Enron, WorldCom, and Tyco. The regulation protects the general public and shareholders from accounting errors, fraud in enterprises, and it helps to improve the accuracy of corporate disclosures.

SOX is a big responsibility for public companies but for software developers there is a need to understand the basics so that the systems they build and more importantly the process they follow comply with SOX. If you are employed by a public company in US you should be aware of SOX and as with the other regulations complying with SOX probably means you comply with other national rules modelled around SOX. One of the most important thing for software developers for this regulation is that a software developer should not have any kind of write access to production systems that can affect the financial reporting of the corporation. This is not always easy to comply with and you require a proper process which separates roles of development from system administration to achieve this.

Remember SOX precludes software developers from administrating of systems they write.

Here are some of the main areas of SOX that you should know about:

• Responsibility

  Top management is directly responsible for the accuracy, documentation, and submission of all financial reports. CEOs and CFOs risk imprisonment and penalties for failures. Phew… it’s all on the bosses here unless you are one of them :)

• Internal Control

  Adequate internal control structure for their financial records. Any shortcomings must be reported up the chain as quickly as possible for transparency. As a software project lead your responsibility will be to identify lapses or possible gaps in the reporting structure for software failure.

• Data security policies

  Policies for data security and consistent enforcement of those policies is the key requirement. Companies need to develop and implement a comprehensive data security strategy.

• Independent Audit

  Companies need to maintain and provide documentation proving they are compliant and that they are continuously monitoring and measuring compliance for independent audit. This is where the software developers get involved a lot, as they are the ones that have to build audit logs, configurations, versioned histories of data, etc. required to comply.

GDPR

This is the big one, specially because of wide adoption and the fact that it’s recent. The General Data Protection Regulation (GDPR), agreed upon by the European Parliament is a European Union law that creates new rules for companies that offer goods and services to or that collect and analyze data tied to citizens of the European Union.

As EU citizens are a sizable portion of any application available online (which is every app out there) you as a software developer will need to comply with this rule. It’s pretty detailed and has all sorts of side rules to satisfy the multiple national rules within EU. As a developer you probably don’t need to know all the details to it’s fullest but here are some that you should be concerned with.

• Consent

  GDPR requires that all software you write seeks consent from the user before collecting any information. An explicit consent by statement or action signifying agreement to the processing of their personal data needs to be clearly laid out to the users. Remember that data here is wide enough to cover even cookies (and hence all those “accept cookies” forms we see these days).
  
  

• Access control

  This gives the right to the user to have access to the data that is stored in any organization. As a developer this has the huge implication of making it flexible to access data even historical ones when the user requires it.
  
  

• Data Portability

  This requires the organization in control of the data to provide the data in a format that allows for easy use with another controller. As a developer this boils down to following standard data exchange formats

• Right to be Forgotten

  This entitles the users to have the a company erase his/her personal data, cease further dissemination of the data, and potentially have third parties cease processing of the data. And for the software developer this means creating interfaces and technology that makes this possible. One huge concern for the software people in this space is that a delete essentially mean a full delete from everywhere - including historical files, backups, shadow copies, the full works.
  
  

CCPA

This is the new kid on the block and as such is becoming the new thing that every software developer is getting worried about.

California Consumer Privacy Act. (CCPA) went into effect on January 1, 2020, with a six-month grace period for companies, giving them time to comply. If a company doesn’t comply, Californians can file private lawsuits pursuing civil penalties for violations. And as California owns the software world every software company in the world are reading CCPA carefully!

For software developers the good news is that if you are covering GDPR many of the issues on CCPA is also covered, although not perfectly. So you’ll still need to double check. Here’s a great article that compares these two: GDPR vs. CCPA here’s a screen grab from there comparing them:

Software team structures

A common question we get asked by new companies in our field is:

What’s the best team structure in a software company?

Our answer to this question had been an easy one: “as flat as possible” meaning a structure where there are that many levels - ideally no middle managers just the software developers or other technical roles reporting directly to the team lead who barely ever needs to report to anyone above.

This is a great answer. It takes away the biggest problems in software development companies and introduces creativity, ownership and most importantly collaboration. But this answer is by itself not good enough. As a company grows, as it takes in more and more projects requiring larger number of teams which then collaborates with each other the flatness that gave all the flexibilities in a smaller organization starts to introduce confusion and chaos. So some more structure is needed. What that ideal structure might be is a question that’s very specific to the nature of the company in question and the culture that it embraces. For us at Kaz it’s been moving towards more independently operating teams that operate under groups or wings of technology. We call them companies under companies under companies. This may not work for everyone. Today let’s go over some common software roles we hear about and try coming up with generalized views about what those roles are supposed to do. This might give us some ideas about what roles our own companies might require and where to fit them.

Common Software Roles

Some of the common software roles we see in the industry worldwide are as follows:

Chief Technical Officer (CTO)

CTO is a confusing role, it’s a role that requires purely technical skills most of the time but sometimes it needs to be as non-technical as can be. At startups, the CTO is often a technical cofounder and that role is all about jumping into coding and jumping out to join a marketing meeting. But the same CTO role is a large organizations is very different. A CTO at such an organization is mostly outward facing - looking at clients, product and marketing teams and giving a voice to technical angle on all business conversations. Rarely does a CTO at large organization ever dive into the code or even participates in technical architecture. They participate in business development meetings, frequently helping to land large partnerships or sales. Many spend a lot of time evangelizing the development activities of the organization to the wider world: sharing the company’s innovations and discovering opportunities in the market which match up well with the company’s core competencies.

VP of Engineering or Director of Engineering

The Director of engineering’s role is what most people usually think of CTO’s role. This role is frequently responsible for building the engineering team, creating work process of the technical team and establishing the engineering culture and operations. While CTOs often face outwards - towards business and clients, the Director of Engineering faces inward - towards the technical workforce, their daily needs.

The best directors of Engineering constantly monitor the team’s progress, process and culture. She encourages the technical staff to use the right tools, the right platforms, even the right programming libraries. She may have strong views about how the teams should operation, how the meetings should be run, hold specific kinds of meetings at specific times in order to foster better collaboration with fewer interruptions.

In smaller organization it doesn’t makes sense to increase hierarchy by having separate CTO and director of technology. These two roles can easily be fused together in such organizations but as soon as business starts to expand this is one role that needs to split first.

Chief Architect & Software Architect

The architects in a software organization are usually the uber geeks. They are the super star programmers who never wants to be in any kind of management role and want to stay as close to coding as possible. In small organizations, the chief architect is sometimes the technical co-founder who knows that she never wants the responsibilities of a CTO as the company grows. They are just not interested to take all the hassles of customer facing, project facing, investor facing and team management facing responsibilities that comes with the CTO or even the director of engineering roles.

The architect is the person responsible for selecting technology stacks, planning technical solutions, designing collaborations and interfaces between systems, etc. As the company matures, the chief architect may also need to work closely with the CTO and at many companies, the CTO also serves as the chief architect.

Project Manager

This is the big difficult role. Sometimes this is the role that everyone in company is looking at. In most companies this is the role where a technical staff decides the future of her career - does she want to stay in development and aim for architect roles or does she want to go more towards management roles.

A project manger is in charge of managing the workflow of an engineering team. She interfaces with both product leaders and an engineering leader such as director of Engineering or the CTO to manage the work backlogs, monitor the progress of tasks, create detailed progress reports, track milestone, manage burn down charts, etc. In smaller companies the project manager is the multi-hatted role of a director of technology and team lead.

Technical Lead/Team Lead

The Team Lead is the leader of a small number of technical staff that forms a particular team in the project’s workflow. Typically a team lead is a senior engineer who takes on the role of mentors and guides for the rest of the team. Usually, developers report to a team lead who then reports to the project manager to give a summary of what his team is doing. The team lead is usually coding all the time and the team lead role is a more a part-time role she has to take up when the time comes. In some companies she may be responsible for the team’s code quality, code reviews and managing the team’s output standards.

Various software engineering roles

At the team level are the real workers in a software company - the people who really make it all happen. Based on different levels of experience you have some of the following roles.

• Principal Software Engineer

• Senior Software Engineer

• Software Engineer/Developer

• Junior Software Engineer/Developer

• Trainee Software Engineer/Developer

These are the people who gets things done, who write the code according to spec, fix bugs and creates solutions to problems.

So these are some of the basic roles. But what happens when we look at the giants like MS or Google? With technical teams that are size of small towns obviously having just few levels in the roles isn’t enough. So for Software Development Engineering (SDE) roles there are hierarchies and more levels and structure. Just to get a glimpse, I’ll close it up today with a comparison of the software roles at our 3 giant friend’s.

Living with bugs in released software products

Bugs are the reality of software. We hate them, we do everything we can to get rid of them but they are always there and we have to learn to live with them - that is we have to manage the bugs and fix them in a sane way. This is important. Actually trillion dollar important. in study done by the Austrian software testing firm Tricentis, software failures cost the worldwide economy over $1 trillion annually!

The same report also found that software failures have caused more than 315 years of lost time and have affected approximately 4.4 billion customers. Software failures also have a massive negative impact on the reputation of companies. The companies surveyed by Tricentis lost an average of $2.3 billion of shareholder value just on the first day after announcing a software failure. No wonder that so many companies keep quiet about bugs. Yet that is probably the biggest mistake. The trick is to learn live with the bugs as a reality and have a practical and realistic process for managing bugs in live products. Today’s post is an attempt to summarize some of the strategies we found as the best for managing bugs on live products.

Accept bugs

This may sound obvious, but you’d be surprised how many companies treat bugs as something totally unacceptable and creates all kinds of penalties and punishments when bugs start surfacing on a product. This behavior comes from not understanding the nature of software products. Yes, the goal is always to have a bug free software release, but the reality is that there will always be some. So the goal should be:

“Release with as few deadly bugs as possible”

Accepting bugs opens up the possibility of a realistic software development process with healthy bug identification and resolution strategy. So this is the first step - for the management and for the technical team leadership.

Make finding and reporting bugs easy

Real life story:

A group of security researchers were prepping for a major reveal in 2013: They planned to disclose at a D.C. cybersecurity conference how a security flaw in luxury vehicles could let bad guys break in without keys and start the cars.

But Volkswagen stopped them, winning an injunction in a British court after arguing that publishing a paper detailing the problem would "allow someone, especially a sophisticated criminal gang with the right tools, to break the security and steal a car,"

https://www.theguardian.com/technology/2013/jul/26/scientist-banned-revealing-codes-cars

After you’ve accepted that there will always be bugs the released products your next sane thing is to setup a process and workflow for identifying and resolving bugs. It’s just crazy how many software companies out there try to hide their bugs or try their best to make it difficult for people to report them. There are literally hundreds of known cases where large companies tried to stop reporting bugs in their software - just making their users suffer even more.

This line of thinking is stupidity defined. You just cannot stop people from finding bugs. What you should do is make it easy for people to find them for you. Have easy ways for reporting such bugs - such as customer support emails that can easily turn into bug reports, a bug reporting page like Facebook’s Report a Bug feature.

On your development team’s side also have the tools for keeping track of all bugs that are being reported - both by customers and your QA teams. Tools such as Jira are absolutely essential, just as important as the software development tools or issue trackers when the actual software was being developed.

Involve customers in the bug finding journey

This needs to be a management and marketing level decision - involve your customers in the bug finding process. Ask them for feedback, have formal ways of checking back for issues, reward them with freebies when they find bugs. Customers are the ideal QA of a software, they use it everyday and they use in ways that your dev team would not even think about using a software (e.g using MS Word for image editing or Power point to make web pages!).

Microsoft has a thing called bug bounty which literally inspires users to spend time to find bugs and be rewarded for such efforts. Google has it’s various reward programs for finding defects, these are all examples of far sighted companies who have not only accepted bugs in live products and made it easy to report - they are actively involving the customers in their journey to find and ultimately fix those bugs.

Have workflow for updating users about bugs

As you accept bugs as reality, your wording and communication will let your users also accept them and make them expect you to come up with fixes as soon as they are found. They also expect you to be mature about bugs found in the current system and have a place to know about such bugs and the status of those fixes. User forums are great for such things and modern ones like Zendesk or Uservoice and many others like them do a great job of updating users about bugs, getting their feedback and letting them know when things are fixed. They have also the feel of user communities and can lead to bigger and better things such as users helping each other out and users forming their own groups to teach each other.

Create a culture for celebrating finding and fixing bugs

Finally, the most important thing of all - within your company and your development team create a culture of celebrating the finding of each bug and fixing them. Some companies make the fatal mistake of making the dev team feel bad each time a bug is found - this creates the negative emotion that takes away the enthusiasm and spirit the team needs to polish off a released product over time. To a dev team the release product is their own creation - any bug would sound bad to them anyway, it defeats the purpose if the company culture is to make them feel worse. The culture should be that bugs are unfortunate yet inevitable - but once found how fast they are resolved and an updated software is released is the true sign of a great software company.

Trust me on this, after more than two decades in this bug creation, I mean software development business, this culture fix is the biggest thing that differentiates a great software company from the others.

Top Web Developer

How do you become a great web developer?

A question that we get often. Here’s our quick round up of the skills necessary to become a top web developer in Bangladesh (well anywhere, but we speak from the context of Bangladesh).

Foundation Coding Skills

As a professional web developer you will be learning many technologies and programming languages but some things are foundational. They are the absolute musts and you build everything off those. In other words you can never be a top web developer in Bangladesh or anywhere in the world without these coding skills:

HTML

The web is HTML. So you better be an expert of this. Simple.

Regardless of the platform, programming language, framework or library you use HTML is what you are going to work with on the user’s view (read interface, read front end) side.

HTML (HyperText Markup Language) is the standard markup language for creating websites, and HTML documents made with little sections that are marked by “tags”. Although there are close to a 100 official tags, you only need a few most of the time (here’s a great page that lists their top 10). Learn them and the rest you can just google whenever you are confused.

CSS

CSS or Cascading Style Sheets are the styling structure for all web pages. As such you can’t live without them. Every beautiful web page you see from Google to Facebook has CSS in the story. So you have to learn it. This is the 2nd area where you have to invest your energy well. The skills you learn on this investment will stay with you forever.

Great thing about CSS is that it saves you time. Things like CSS selector classes, can let you manage the style of multiple pages from just one place.

Just as HTML there’s a lot of CSS things to learn, but you can get away by learning the top ones and use Google for the rest of your web development career! Here’s a great list of must know CSS.

JavaScript

Javascript is a browser side computer language that makes web pages interactive. There are other languages that you’ll need for web application development, like PHP or C#, you’ll need to know them when you work on the back end but for front end Javascript is the only language that matters.

When you start learning a language like Javascript you start thinking like a programmer. This means that this is where you encounter algorithmic thinking, which is the bases for solving all the problems you will face as a programmer.

Tool Skills

Once you’ve mastered the foundational coding skill above learning the tools that you use is essential. The graphics here shows the most popular IDE (Integrated development environment) tools (source: Stack Overflow).

What you learn will depend very much on what code you are working on, so you don’t usually get much option there. But if you are learning on your own then you might use this to decide to pick up the tool that is most used. At the top of the list is Visual Studio. Makes sense as in the last couple of years, it is the tool that has made the most progress and is the most frequently updated. The number of extensions is growing and so is its community.

Code Versioning Skills

Code version control let’s you to track and maintain the code you work on. This is an absolute must skill for any web developer. Imagine a situation where you make a few small changes to your code and then the whole application stops working. It’s obvious that the changes you made has caused this and the fastest fix would be somehow to rollback to where you were. A version control system let’s you do just that. That is why it’s absolutely necessary.

Version control systems like GIT enable you to make mistakes without consequence. They are also necessary when you're cooperating with other web developers on the same code, they let you share code without worrying about breaking things.

Most popular versioning tools are GitHub, GitLab, MS Teams(TFS), Mercurial, etc. You should start with some flavor of Git as that has all the core concepts in place and it’s very likely you’ll end up working with a Git based system.

Graphic design Tools

In theory a web developer doesn’t really work on graphics - a designer does. But that’s just in theory. In reality you’ll find you have to dabble with graphics all the time. And if you don’t have some basic skills on graphics manipulation you’ll feel that you are getting stuck at every stage and waiting on someone to come and rescue you. Some popular tools for graphics include PhotoShop, Figma, Zeplin and Sketch know them a little bit at least by features and then try to learn at least one of them well.

Back-end and Databases Skills

Once you have mastered the part of the web site that the user sees the front-end, you have to move to the servers side - the back-end. On the server side you have the code and also the data storage - Database. The technology choice is massive here and you have to pick one or two focus on. The following graphs show the most popular languages (both desktop and web) and the most popular database technologies from the stackoverflow study. Use this to get an idea about what you should focus on if you have a choice.

Libraries and frameworks

Now that you have become used to the core skills for a web developer it’s time to focus on specialized libraries and frameworks. These make your life easy by doing all the hard lifting. With these libraries you can quickly get the basic structure of a web application up and running and then focus on adding features. This is a huge area by itself so I won’t go into the details but give you another graph of the most popular libraries out there currently. Know that no one actually learns all the libraries, you’ll focus on one or maybe two that you become real master of. The rest will only be used if you absolutely need to for a project.

Deployment and Hosting Skills

Now that you have made an interactive stylish web site, using HTML, CSS and JavaScript with a server side technology you love and a great database to store your data but how do you make it available to everyone on the internet? You’ll need to deploy it on a server and host it. Web hosting let’s you to store your resources (HTML files, CSS file, JS files, images, database) on a server that has internet connectivity and is accessible to everyone with a browser and an internet connection.

There are thousands hosting providers out there, learn the name of some good ones. Compare them and know their features. The other things you’ll need to know is how to get a domain for your app, how to point that domain to your website.

The #1 software soft-skill

A common question we get asked is: what are the soft-skills that a software developer needs? The answer to that question can be pretty big and some of the candidates can be very surprising (e.g. marketing skills - for advertising yourself in the new job market where employers actually find you rather than you find employers). But if the question is rephrased to:

“What is the the #1 soft-skill that a software developer needs?”

The answer is super easy. There is no confusion here, the answer is:

“The ability argue with logic”

Why?

Because, the software profession is all about debating and arguing what the correct solution to a problem is. There are no final or perfect solution out there. What works for one problem doesn’t work for another. What works today for a certain situation may not work tomorrow. There are just too many possibilities and there are no silver bullets! Nothing is sacred in this space, if “normalization” was the one thing that everyone agreed on data storage strategies (aka databases) yesterday, “de-normalization” could be (and is) the flavor of the day today. We have to live with the possibility that everything we believe in is probably wrong! So the only way to find solutions in this sea of uncertainty is - debates. Rational debates where every argument is proposed with logic and countered with logic. From such an exercise, maybe, just maybe a consensus may be reached. Or, what is more likely the common situation, no consensus is reached but a decision is made one way or the other with the pros and cons of that decision clearly out in the open. This is the only way to make progress.

Emotion destroys a software debate

In this scheme of things the worst possible situation is a debate where arguments are not based on logic but on emotion. The classics in this area are statements like “Relational database is the only way” or “Nothing is better than Java and I don’t want to hear anything else”, etc. These lines and people who make these lines are detrimental to the progress of a software project. They need to be killed, erm sorry, I mean they need to update their soft-skills and learn how to control their emotion and fight it out with logic (and data where possible).

An unpleasant reminder

I was reminded of this recently in an unpleasant way. We run a series called the career booster on youtube - it’s planned as series of shorts in Bangla language about what to do to prepare yourself for a career in software. The target is mainly students and early stage professionals. The third video came out a few days ago and it had the unfortunate title of “Programming languages NEVER to learn”! By itself it’s a mistake to have a title like that because it’s plainly wrong in our field (every language including the dead ones have a place and need and people do need to learn them). The correct title could have been “Programming language not to learn as a beginner” or something like that. But the cardinal sin was that the “NEVER” to learn languages included the mother of all languages C/C++ and the other big god in the pantheon - Java! With a lineup like that a storm of protest was inevitable. The social media became buzzed with hate pointed at us (and at our idiocy). Several influencers picked up on this and we walked in shame. The hate was fully well deserved. We took the video down and tried to come up with various forms of apology and lame explanations.

Needless to say, a complete mess!

But in this huge mess at least something positive came out which is all about today’s topic about the art of making your arguments with logic. Among the literally hundreds of comments (I really mean hate messages here :) ) there were some clear patterns. Some were just awesome killer retorts that proved beyond a shadow of doubt that our video was totally wrong and why it was wrong. And some were irrational and emotional banter that added no real value. You could easily separate out the professionals from the not so professionals in our field just by looking at the comments. Let me go over some of the good ones here to highlight what works great in software. But before I do that that let me restate, the great thing to know is that:

the ability to argue well is a skill and it can be easily learnt.

So being aware that you need to pick up this skill and then practicing some caution to keep your emotion in control and your logic in hyper-drive you can hone in this skill.

Back to the comments. There were some super awesome comments. They were precisely worded, designed to hurt yet made with logic and data that is so undeniable that you can just cry and look at yourself in the mirror and try to remember where and when you lost your brain :) Here’s a particularly good example, and I’ll point out the qualities that make this such a good one:

Clarity: Notice how the writer takes a direct jab at our lame excuse of saying that we had a plan to start a debate with the video (actually partially true but very badly executed). The jab is very sharp yet it is cloaked in the wording of being helpful i.e. “… hurting people’s career, which is misleading.” Precise, to the point and without any strong emotion. The write is just expressing his concern clearly and the opposing side has to either answer back or just accept it as correct.

Supporting logic/data: Then comes the killer - data. If you have solid data as your proof for any argument it is the show stopper. The writer clearly shows that at least in the job site indeed.com Java and C++ jobs are at the top thereby proving that the main goal for our miserable video - career betterment was not met.

Suggested solution: Then comes what I think is the master stroke of any good technical argument - some suggestion on how to improve things now that crack has been identified.

I am awed by a retort like this. Software developers like this person will be an asset for any team where he works. He will make debates short by cutting out the fuss and the endless bickering. He will make his point strong and believable and thus acceptable to other team members including the opposing group (assuming they are not emotional or illogical). And he will suggest a solution and reconciliation that will help the team heal and move on. Awesome!

Here’re two more good ones in a different ways, one points out a clear issue and basically is asking us to address it. Important for any tech discussion where you throw a logical question to the other side and ask them to explain it. The other one in Bengali is purely on the solution space trying to turn the issue into something useful rather than bicker about what’s obviously wrong.

The Survey

We’ve gone over several Facebook pages and filtered out about 300 purely negative comments made by people with software background (as given by their profiles). Overall, on our rough survey only 20% or so of these comments would qualify in some way as a logical, data driven and solution driven argument. The kind of argument we love in technical debates. This is worrying but this data could be an unreliable metrics of the reality as people don’t always stay very rational or professional in a social platform like Facebook. It would have been interesting to run this on a professional network like LinkedIn and see what the data is like. But hey, that’s not going to be us! This was too traumatic and we are done self-mutilation for the year :)

Anyway, gotta go, have fun, stay logical and stay with C/C++ no matter what career videos say. btw, our next career booster video will be about this very topic but we can’t find our actor, he is in hiding after this storm… joking of course! Should come out pretty soon.

A killer tech CV that no company can refuse

Our last blog post about cool beginner web projects was a super hit! Over a single day we had dozens of email asking for more ideas, some suggesting even cooler projects and others saying we should put up example codes. Thanks everyone for their suggestions, ideas and critique. Staying on the high note, I decided I should describe an ideal resume concept for software developers: A CV which is itself a show of skill, which is a CV - I’m calling it the:

“The Recursive CV”

The idea is pretty simple, and I’m surprised that I’ve not seen anything like this yet. Let me explain what I mean by a recursive CV and why it’s great. But before I do, let me also go over a big problem with the concept of CVs that currently exist.

Problem: CVs are not proof of skills

All CVs look the same!

It’s true. On an average we receive at least a hundred CV a month, and if there are job adverts out that number reaches a thousand easily. On a surface level most CVs look different, they have different formatting, their content is different (obviously!) and structurally they are similar, as they should be to some extent. They have the usual contact detail, experience, skills, references, etc. But the way they are all the same is that there is almost impossible to differentiate one candidate from another based on the content of their CV. They all tend to have similar skills, more or less similar experience blocks, almost the same number of references. So when we are looking for a particular experience set (e.g. C# web development) and a particular experience (say 3 years) we end up with literally hundreds of CVs that are equally a good fit. It’s impossible to go over all. So we take shortcuts, every employer does. Each of us have some tricks, secret hacks that are essentially heuristics. For example I check if there are any misspelling of technology names (e.g. .net instead of .NET) - very superficial, I know, but we have to find some rationale for not doing hundreds of hours of interviews :)

The big question we always have for tech CV is:

Does this person really have the skills he/she is claiming to have?

And I’ve rarely found a CV that answers that question by itself. There are exceptions, I remember a horribly formatted CV with several misspelling of technology names that I was going to delete right away - but I happen to see the last line of the CV that said: “I implemented a .net based JVM, here’s the link…”. Thankfully, I noticed it. The guy turned out to be a freaking genius named Maruf Maniruzzaman, who as it turns out doesn’t need to write his CV well. He ended up being directly hired from us by Microsoft, and now does rocket science level robotics programming at Amazon. Btw, he is coming to our deshi tech adda next Saturday (see the poster here for more details).

OK, I’m digressing. Back to the original problem: it’s not easy to find proof of skills in the typical CVs.

Solution: Make your CV a proof of your skills

If you could come up with a CV that was by itself a proof of your skills that would make things so simple for everyone. But how? Well, this is what you’ve got to come up with ideas. But here’s an example of such a “recursive CV”:

You write a little Javascript app that shows your CV as an interact-able web page. You could have the timeline of your experience, have fancy fold outs and fold ins that show information but also shows your CSS and JS skills. Maybe a search that shows how good you are with suggestions. A skills tag cloud that can lead to GraphML based viewer to show off your project experience? The options are limitless. What would be great is if you could show how you are doing each piece of the CV, some code snippets, etc.

The CV itself is a show of your skills.

If you want a hint or some starter code to move in this direction here are two great example codes:

Building a Vertical Timeline With CSS and a Touch of JavaScript

CSS Timeline

OK, that’s it for now, hope this post will help you to think something new about your CV. If you make something make sure you send us your “CV” to hr@kaz.com.bd we are always on the lookout for people who are different and exceptional.

Cool web projects for beginners

Today’s post will be slightly different from our usual topic of helping startups, software teams and company culture. You gotta do something different sometimes, right? And this topic comes from a lot requests from CS students and fresher software engineers who wants to pick up a “hobby” project that'll teach them some interesting things. These projects are really important for freshers because:

1. Perfect thing to practice and improve coding skills

2. Great for playing with new technologies

3. Awesome thing to mention in the resume!

Plan on using an up and coming javascript library (e.g. ReactJS, etc.) or a new new library in your favorite programming platform. The goal should be to learn something new while doing a fun project. So here goes, our list of cool beginner projects.

The Image Manipulator

Every web developers need to become a guru in manipulating images. Any good web app these days rely on some kind of images tricks and gimmicks.

Features

The image manipulator can be a bunch of image operations tool. But the first feature to focus on should be image rotation. Here’s how the first version can be like:

1. It will start by displaying a square pane showing an image in a 2x2 matrix.

2. A set of up, down, left, and right arrows next to each of the images the user can flip them vertically or horizontally.

Challenge

You can only use native HTML, CSS, and Javascript. Image packages and libraries are not allowed.

Hints

How TO - Flip an Image

The Book Finder (using an API)

The book finder is an application that lets users to search for a book. The user can type in any text such as the title or author of a book and the app will display the resulting books in a list on the page with small thumbnails of the books.

Features

1. The home page is a google like page with a search box where the user can enter any text.

2. When the user submits the search, the app will call an API (see below for possible candidates) that will return an array of books and show additional information about the books.

Challenge

Make the app a single page application (SPA).

Hints

Google Books API

Is there an Amazon one? Does Google books API give you thumbnails?

Memory - Card Game

Have you played this game with cards? It’s a card game where you have to click on a card to see what image is underneath it and try to find the matching image underneath the other cards.

Features

1. The app opens up with a home screen where the user can see a grid with n x n cards. All the cards are faced down initially

2. The user can click a button to start the game. When this button is clicked, a timer will start

3. User can click on any card to show the image it. The image will be displayed until the user clicks on a 2nd card.

4. When the User clicks on the 2nd card:

   a. If there is a match, the 2 cards will be eliminated from the game.

   b. If there isn’t a match, the 2 cards will flip back to their original state

   c. When all the matches have been found, the User can see a dialog box showing a Congratulations message with a counter displaying the time it took to finish the game

Challenge

Only HTML, CSS and Javascript allowed.

Hint

Example project

History chart for GitHub

This project, a bit advanced but fun will provide a visual history of a users GitHub activity.

The goal is to produce a timeline containing each repo and annotated with the repo names, the date they were created, and their descriptions for a user of GitHub. This is a great great project for the resume since it can then be shared with a prospective employer. Of course, only public GitHub repos should be displayed.

Features

1. The app starts by taking in a GitHub user name

2. Then the user can click a ‘Generate’ button to create and display the named users repo timeline

3. There needs to be validations for wrong user names etc.

Challenge

Stick to HTML, CSS and Javascript if you can.

Hints

GitHub has two API’s to access repo data.

Documentation for the GitHub API can be found at:

• GitHub REST API V3

• GitHub GraphQL API V4