Develpreneur: Become a Better Developer and Entrepreneur

This episode starts a new series on creating a small software product.  Our goal will be to create a passive income application that we can launch within a few months at most.  We will get started on our new product immediately, so let's dive right in. Selecting A Problem Every good product solves a problem.  That is where we will begin.  Think of a problem that you deal with on a regular basis that could use a solution.  This might be a familiar and repetitive task or something you do manually that would benefit from being put in a computer. Once you have a problem to solve then move to the time you are willing to invest.  You might only have a few hours a week or can put in 40 or more hours on a weekly basis for a few months.  This effort/availability will profoundly impact the scope of what you can accomplish. Getting Started Any time we want to automate something we first need to define what that something is.  That means we need to detail the process that will solve our problem.  This may be a few steps or dozens.  Once we have documented our solution, we can look at our bucket of hours to put into this and assess where we can automate steps. This leads us to the definition of our product and its requirements.  At this point, we do not have to get too detailed (we will add detail later).  That is enough looking ahead for now.  It is time to get started on our product. Your Homework Your assignment from this episode is to get started.  You may struggle coming up with ideas.  However, no idea is too simple or too small.  You can always expand on it later.  I have even provided a template for you to follow to get started.  We will add more content in future episodes.  Nevertheless, this provides a place for you to start and if you need help feel free to leave a comment or send an email.  Good Luck!   ProductCreationWorksheet

The ability to generate a passive income is a desire most of us have.  We may not recognize it as such, but the desire to live without having to work seems universal.  A challenge with this goal is that we often focus on completely being self-sufficient with our passive income.  Although this is an understandable goal, it can be too big and cause us to lose hope in it as possible. Paid To Have Fun One alternative to being self-sufficient is to love what you do.  When you get paid to do something you would do for free, then you might as well consider yourself retired.  You can do that the rest of your life.  This situation is not only ideal; it is achievable early in life and at almost any stage.  That is not a passive income though; you still are required to do something for that money. Early and Often Any good book or article on saving money will point to the impact of time on savings.  The earlier you start saving money and investing it, the more your money can be put to work for you.  This is the original form of passive income.  There is an allure of building a site, creating a product, writing a hit book, or one hit wonder paths like these as a way to generate passive income.  The struggle is to get something that hits big enough to move forward on its momentum.  There is a lot of work that goes into these achievements, and often they require skill and some luck as well. If your focus is on using your money to make more, then you need less skill to do so.  Better yet, this has never been truer than it is today.  There are options for micro-investing in a broad range of areas that allow you low-end entry and excellent return rates.  Therefore, you can test out several strategies to find the ones that work best for you.   Get Started Real Estate: https://fundrise.com/ Loans: https://www.lendingclub.com/investing/alternative-assets/how-it-works Products: https://microventures.com/ Ideas: https://cashcofinancial.com/2018/02/8-micro-investment-options-that-will-work-for-your-tight-budget/

When you look at concerns that keep business owners up at night, a few show up over and over.  One of these worries is the challenge of securing your systems.  No one wants to be the company mentioned in the latest data breach.  Unfortunately, security can be expensive.  It is an open-ended goal that can allow for a lot of resources to be poured into it. Achieving the Minimum The first step in securing your systems should always be to get to the expected minimum level.  The tasks required to perform this vary from platform to platform and line of business.  You can hire a consultant to assess your systems and point you to the minimums, or the same data (roughly) can be found in an Internet search. The standards set out as minimums in securing your systems are almost always based on well-known risks of those systems.  Thus, when you get to the minimum, you are blocking a substantial majority of hacker attacks.  Yes, you will be attacked if you have a website or system that can be reached from the Internet. Technical, but Understandable The recommendations you will find (or a consultant will share) walk through technical steps and configuration details.  However, the goals of the action and how it impacts security are often practical and can be understood by non-technical staff as well.  As a leader, it is highly useful to understand (roughly and at a high-level) what has been achieved when you complete these tasks. Above and Beyond Once you have the minimums, the hard work begins.  This is where you are asked to decide whether additional investments in security are needed.  The calculations for extra protection include risk reduction and are not cut and dried ROI decisions.  However, some guidance can be found in examining the steps often taken in your line of business as well as reviewing the requirements of any compliance needs (PCI, HIPPA, etc.).

Of all the applications I have worked on over the years a code generator is the most challenging.  Likewise, it is the most rewarding and painful sort of project.  This is not something for the faint of heart.  However, it is an incredible learning experience and often will help elevate you to that next level. Reinforce Best Practices Do not misunderstand me; a code generator can create some ugly code.  However, building an application that creates source will often push you to best practices.  Your head will explode if you try to debug sloppy code.  Thus, the time you spend in formatting the generated source and making it easy for a human to read will be a good investment. There is also the end-user to keep in mind.  Whether you are generating source for personal use or as part of a commercial application, it pays to make that code top-notch.  There is no sense in building an application that spits out source code you would be embarrassed to share, or that will immediately fail a code review. The Incremental Approach The concept of an application building an application can be overwhelming.  Instead of trying to tackle the code generator features as a whole, take it a piece at a time.  You will have some simple tasks early on that can help you get used to the idea of generating code.  This simplicity is often tasks like creating a formatted template or header file.  The dynamic portions of that output typically are minimal and amount to little more than placing some strings in the right place. These early steps are often a perfect way to define and test your approach to code generation.  You might try to build everything on the fly, or it might be okay to fill in some template files.  These are not mutually exclusive approaches so you may find the first steps in splitting out the pieces that can be a snippet or template from those that need to be entirely generated. More Common Than You Think Full-blown application generating applications are typically vast and enterprise-grade solutions.  On the other hand, we can find needs to create code (or something like it) on a regular basis.  This may be dynamic SQL for a database function, a configuration file generator, or even small tasks like a moderately intelligent log writer.  Generating content that will be validated by a parser or compiler is one of the more daunting coding challenges.  Nevertheless, it is one we must overcome to become a better developer.

Our modern lives are full of work and tasks that can leave us exhausted at the end of the day.  This hectic pace can often keep us from doing the things we enjoy.  Never fear, in this episode, we look at ways to organize your week and day to create free time for the things we enjoy. Filling The Bucket The concept that is the basis for this approach is that of filling a bucket with ever smaller stones.  Our tasks have size and time requirements.  Thus, we have larger tasks that take big blocks of time and small items that can be accomplished in minutes.  Those smaller tasks may be just as important as the larger ones.  However, our ability to "squeeze in" those smaller tasks throughout the day is essential to create free time. We have "dead" time sprinkled throughout our day.  This can occur when waiting in a checkout line, commuting, or waiting on others.  We want to avoid checking out of life in order to accomplish these tasks, but it is easy to find some balance where we can get more accomplished in the same amount of time. Planning is Critical These small tasks can require almost as much time to get started or to remember they need to be done.  That is why it helps to have a list (mental or physical) maintained that includes these items.  When you have a list, you can scan it and grab a task from the list instead of having to think through what might need to be done and be small enough to handle in your dead time. Although these tasks may be a high priority and need to be done today or sooner, it works best when the items on the list can be done sometime this week or month.  That reduced priority allows the tasks to stay on your list until there is a perfect time to tackle them.  Of course, you can also periodically make this list your priority and work through whatever is left over on it.  This keeps tasks from becoming "stale" or falling into the too little, too late category. Better Than Angry Birds I am as guilty as anyone of using my phone as a way to entertain myself during the dead times of the day.  However, those entertainment breaks do not add up to the enjoyment I can get with more free time at the end of the day or week.  You might have to break your Angry Birds or Candy Crush habit, but the payoff will make it worthwhile.  Give this a shot.  You will be surprised at how much extra you can get done each day.  It is not magic, just a way to effectively create free time.

When we plan our way to becoming better at anything we have to find a way to grade progress.  Thus, measuring is a critical factor in improving our performance.  We can try to achieve success with something that is not measured.  However, how do we know when we have made an improvement or when we have gotten worse? Measuring Provides Our Pace We often talk about becoming better developers.  In doing so, we assume that there are specific ways to measure our progress as a developer.  These metrics include coding skills, problem-solving productivity, job difficulty that we can handle, and more.  The way we track progress is a vital part of how we plan for improvement.  Just as a lack of measurement inhibits declaring success, the granularity of our analysis has the same impact. As an example, pretend that the smallest measurement was a foot.  Inches do not exist, and there is no way to have a partial foot.  Thus, things are 1, 2,3, or more feet tall.  If you are 5'7" and your friend is 6'1" your heights would be five and six feet tall respectively.  On the other hand, add five inches to both heights, and now you are the same six-foot height.  In a race, you might get six inches closer to the person ahead of you, but you would still be a foot behind them using that approach.  Thus, you improvement has to be at least a foot at a time to see any at all. The Abstract is a Challenge The differences in heights are apparent without worrying about measurements.  However, abstract ideas are not so easily distinguished.  A classic example of this is how we measure developer productivity.  There are fundamental differences in measuring by lines of code written, function points, or hours of time sitting at a keyboard. This leads to our challenge in becoming better.  We need to choose a way to measure progress that fits our goals.  Thus, we are back to defining our "why."  Before we embark on a journey of self-improvement, we need to establish and refine our goals.  Becoming wealthy is not likely a goal.  Early retirement or the ability to travel is a better target.  How many of us care about the amount of money we have outside of what that can buy for us? In this episode, we look at ways to measure our progress as part of servicing the "why" that points to our ultimate goals.  In doing so, we might find that our journey is not as long and arduous as we thought it would be.

Most of us were just getting started on our career when we were introduced to coding standards.  These are common in the industry and more so where there are entry-level developers.  Although the purpose of coding standards is often related to easing team development, there are far more benefits as well.  Thus, you should create these for your improvement as well. Coding Standards As A Productivity Tool The first benefit you will get from a standard approach is a template for writing code.  We spend more time thinking about naming and structure than we realize.  This cost dwindles away as we gain experience because we do tend to have standards we adopt.  This occurs even when we do not have any documented standards. In fact, your coding standards are essentially your coding style.  These are important as they are how you get into a coding rhythm or "the zone."  The rules and guidelines reduce the overhead incurred by making little decisions (format, names, spacing, etc.) and help us focus on getting work done. Looking Professional You either have or will be asked to share some of your coding examples.  This is just too common as a way to assess developers outside of their knowledge of syntax.  One of the things that will jump out at a reviewer is whether there are standards followed in your code.  When your source looks like it was written by a small army instead of an individual it is seen as "spaghetti" or low quality.  Note, this impression has nothing to do with actual functionality and quality.  However, it does set a negative tone for the reviewer. Helping Your Research and Debugging When you have standards you stick with then it will be far easier to read and review your code.  This advantage applies to you as much as it does others.  Thus, you will be glad of your consistent approach when tracking down a nasty bug or trying to go back over code you wrote six months ago.  Good structure and standards help you navigate through the source quickly and with fewer bad words muttered under your breath.  In short, it can turn a bad experience into one that is surprisingly easy.

The Gig economy has many facets.  One of the big positives for many people is the option of remote work.  There is a freedom that comes from being able to get away from a desk and an office outside of the home.  This goal is achievable.  However, some planning is required to be productive while working remote and making this your regular routine. A Good Workspace We have discussed your workspace in a recent episode and touched on a home office.  That is a good starting point, but remote work requires some tools as well as an eye for comfort.  For example, you need to have a reliable Internet connection, a way to be reached (cell phone is ordinary), and general office tools like a printer. These items are not all requirements but will help you be productive and get more out of your opportunity.  When you first try out remote work, the lack of these tools and items will slow you down.  Thus, you can note the need for them and adjust before your next time.  Of course, it is best if you know what you need before you get started.  Make a list of the items you use in a typical workday.  Once that is complete, make sure you can use or replace each of those items while working remotely. Support, Information, and References The most negative impact to productivity with remote work is a lack of handy reference material.  Although the Internet has reduced this problem, there are still bits of information you have within reach at work that may not be around at a remote location.  If your job requires regular reference material like a phone or who to contact list, then make sure you put these in digital form on your device. The help desk number or email address is almost critical to have available if you work in a corporate setting.  This contact information is data you need to have from the start.  In fact, it is most valuable when you first start on the path to remote work.  It is common to run into issues like firewall access, VPN credentials, and other data that only applies to remote staff.  Thus, you may not know what you do not know until you try to get some work done at a remote location.  

When you need to create a minimum viable product (MVP) the process is not that different from designing any other product.  However, the process is more challenging.  The process requires tighter control over the scope of requirements through to deployment.  This type of product is becoming a standard way to step towards funding and is worth closer examination. Why Create An MVP? As with any software product, the decision to create an MVP needs to be made.  Thus, we need to look at whether an MVP is a better choice than a full-blown product.  The first thing to understand is that an MVP must be a product that has value and is usable.  That is the "V" of the equation.  It may seem contradictory, but you need to have a good idea of the full product to decide whether an MVP is the right choice. I have found that starting with the full solution and whittling away to a smaller, yet viable, application is the most straightforward approach.  When you do this, you have the complete picture in mind while you are taking off less-important pieces.  It is harder to start with nothing and add in features until it becomes viable.  This approach also makes it easy to look at the differences between the minimum and full product.  When those two versions of the product are very close to the level of effort, then an MVP is not a good choice. Throwing Features Overboard The hardest part of the minimal approach is finding out what can be pushed off and workarounds that are needed to compensate for missing pieces.  There are best practices that we want to embrace.  However, those approaches may be a bad thing for the minimum product.  This includes some potentially significant aspects of a product like scalability and even stability. I assume that the funding and resources available once the MVP is accepted will be enough to correct any shortcuts you take.  If that is not the case, then you will have to avoid some (or all) shortcuts while building the minimum.  Focus on what the user sees and experiences.  This makes some features easy to drop.  For example, any administrative functions should be assumed as not needed until a strong case be prepared for them.  Long-term features like archiving data and large-scale reports or features are also obvious candidates for the "future" list.  That enterprise-class solution you vision at the end is not what you need when just starting out.  Therefore, any feature that is only moderately useful (or less) when users are just getting started with the solution is one that should be pushed to the future. The Bottom Line The goal of an MVP is getting to market with a minimum investment.  Thus, we want to focus on implementation and the core features.  Any feature that is not directly related to the main problem being solved should be skipped.  Once you have stripped down the elements to bare-bones, add what you need to make a useful application.  Beware of features that increase the mass appeal.  You only need to provide a minimal appeal for the solution at this point.  In particular, appeal to the investor(s) and your MVP will be successful.

We have looked at certifications before.  However, now we go a little deeper in our final part of the development languages overview.  The bulk of this episode focuses on development language certifications, and then we go back and look at some related to databases and other tech areas. Development Language Certifications as a Learning Method The best part about working on certifications is the experience and know-how they bring.  A certification test is going to be wide-ranging in topics it covers (within the language) while pushing/implying best practice approaches.  This approach to learning is often more complete and useful than on-the-job training provides.  Many companies have a path to using a language that ignores best practices or lacks full utilization of the environment.  This situation is why I often recommend that new teams in a platform include at least one or two certified members. Stacking Certifications Many certification programs have tiers that build on each other.  Thus, there are low-level certifications that are useful (or required) for reaching the higher levels.  Although it can be exhausting to do so, I highly recommend batching your cert process.  There is a mindset that helps in taking these exams and studying for them in bunches helps instill that focus.  This situation can help in finding the best answer as well as getting a feel for "trick" questions that may through off your score. Not a Slam Dunk Certifications are an excellent addition to your resume.  However, they are not an easy thing to complete.  The whole point of certifications of all types is to provide a proof that you know the technology and how to use it.  This goal is not something everyone can achieve, nor is it one that even skilled developers will ace without a good deal of effort.  Make sure you are ready to sign-up for some additional work and studying on top of your day job when you decide to pursue a certification.