Develpreneur: Become a Better Developer and Entrepreneur

Our series on a consulting side hustle moves into landing a project.  We have set the stage to present our services and "company."  In this episode, we will look out how to use that positioning to find, apply for, and win a project. Stay Happy Early on, we will often take work that is not ideal.  Our goal is building a series of reference projects and we are not able to be too picky.  Nevertheless, the projects to take on for a side hustle should not be horrible.  Look for projects that match your skills but do not stop there.  Keep an eye out for projects that will help you work on skills you want to advance as well as challenges that will be "fun." Your goal should be to land a project you are comfortable completing that also provides you some benefit (even if that is just a steady extra bit of revenue).  As always, when in doubt, look for satisfaction over salary.  That will help you to avoid a side hustle that wears you out. Set and Meet Expectations Most project postings will include some implicit or explicit expectations of your commitment.  They may require a target number of hours worked per week or completion by a specified date.  Do not take a project you are not comfortable with as far as meeting these expectations.  You should also be clear with customers about your schedule, plan, and timelines to ensure expectations are properly set.  Clearly communicating this will go a long way towards completing the project in a satisfactory way. Anatomy of a Proposal There are many ways to create a proposal.  A large project will often require a document that can become rather lengthy in order to sufficiently respond.  These small project sites like Guru and Upwork will have many projects that will not require that much work on the response.  However, a professional response will help your odds of landing a project. I find good proposals have three key parts at least.  These are the header or introduction, the core response, and a wrap-up.  The introduction is exactly that.  Tell the customer who you are in a few sentences.  Focus on your skills, mission, and experience.  A catch that will entice them to read on will help.  I often customize the introduction to address immediately why I see myself as a good fit for their project. The core response should include specifics about the project.  Make sure you address every point they mention and then add any insight you can provide.  For example, a requirement for users to log in implies a registration/creation process for users, and maybe "forgot password" and other administrative features.  Mention the implied features to show how you can add value to the project. A Strong Finish Your last opportunity for landing a project is the close of your proposal.  It is important to keep that in mind as your close your response.  Most of the time this should include a brief restatement of the proposal to make it clear and easy to summarize.  Offer some next steps as well as ways for the customer to contact you with any questions they have. The end of your proposal is an excellent opportunity to open discussion about it and how you can meet the requirements.  So, take advantage of that.  When you can build a relationship with a customer you improve your chances of winning this project or at least being seriously considered. Now it is time to put this to use.  Get out there.  Find some projects.  Then let us know how it goes for you.  If you have any questions, join us in a mentor session to get some reviews and help with your approach.  Good Luck!

In the prior episode, we started out our coding of a solution for a specific case.  Now we move on to the general case problem-solving code.  Some of this work may have been completed in your general solution, but it is worth looking over these to craft the best solution. Input Parameters Our hard-coded solution did not need any parameters or even user input.  However, as we move into the code for the general case problem-solving, we need to add those features.  It is possible to skip the user input step at this time and merely hardcode different values for the problem.  I do not recommend this as it is better to get some user input steps in early so they can be tested extensively during implementation. Security and Validation As we move to a more flexible solution, we need to consider security and validation.  User input can be insecure or incorrect.  This is an excellent time to start implementing checks that the data is valid and the user is authorized to enter it.  We are just getting started on this facet of the implementation, so a lot of placeholder code makes perfect sense for now. More Testing Your tests were pretty simple last time.  Now we are building out the core functionality and should verify it through testing.  We will follow some general rule of thumb steps for testing. Max value in a range Min value in a range one off values of both min and max in a range Empty values Values that are too long There will often be additional testing required to ensure you have not "broken" your application.  However, these are a good start. Your Homework Keep moving forward on the implementation phase of your application.  We hard-coded our way through the last bit of homework.  Now, it is time to break up some of those tightly defined values and allow for user input.  Usability is not the concern yet.  Stay focused on functionality and solving the problem.  We will make it pretty later in this phase.

We built a foundation for our application in the last episode.  Now, we move into solving the problem that our customers will pay for.  This step is just putting our plan on the computer and handling a single case.  Our actions should be defined in our specification to the point that this is relatively easy. Document As You Go A way to approach this step is to start with comments, move to text/hard-coded output, and then to plug in the computations.  When you follow this approach, the actions of this phase follow the checklist below. Pseudo code the process in comments Add console (or other simple output) commands that reflect the comments Use single and hard-coded problem parameters Start with the most challenging step Implement and test the step Move to the next step and repeat Leave output in place and update with result data as you replace hard-coded text with a function or block of code Test the full process as you go This process is tedious for the most simple problems but makes more sense as you move to more significant and more complex challenges. Your Homework This episode takes us through solving our problem in an automated fashion.  Walk through the suggested steps above with your application.  If you get ahead on the work a little and solve for the general case then that is ok.  The episodes break up the implementation to make it easy for large products.  A small product may not need all of these distinct steps. Specific case code example: implement2.tar.gz

A challenge that we all face in our service offering is setting the development pricing.  We know what our salary is and what we would like to earn.  However, we also want to be fair in our pricing to both our customers and ourselves.  In this episode, we look at the factors to consider in setting your rate as well as fixed bid factors. Rule Of Thumb For Rate It helps to start with a baseline.  That is easy math.  Take your salary and divide by 2000.  That is roughly the hours we are expected to work each year (fifty weeks and two weeks of vacation) even though a salaried developer always works more in my experience.  Thus, if we make $50,000 as a salary, our hourly rate is $25.  That should be your minimum unless you want to do the extra work.  This is a side-hustle and not needed to pay the bills.  However, it is never a good idea to devalue your time. Fixed vs. Hourly You will come across projects that ask for a fixed rate.  This puts more risk on you and takes it away from the customer.  That should lead to a higher price per hour for you.  Therefore, the hours you estimate for the project should be billed more than your standard rate.  If all goes well, you should make more money on these projects, but it is sporadic for that to be the case. Receiving The Money At some point, you will invoice your customer and expect payment for work done.  This process should be made clear from the start.  Let your customer know when to expect an invoice, what it will cover, and when payment is expected.  You should also define any discounts or additional (late) fees that they can expect.  Once you have set that schedule in place, make sure you meet it on your end.  If your customer lags in response to invoices then the sooner you bug them, the better.  When you let things slide for a while, you can end up in a situation where you are doing extra work just to convince your customer to pay you what you are due.  This is never good. Some Useful Links There is no chart I can provide that is a perfect way to set pricing.  However, we have looked at some common project pricing challenges in the past and links to those articles are provided below.  Finally, you can adjust pricing from project to project.  Thus, start with small projects, learn your lessons, and then you will be confident in your pricing as you move to larger projects. Pricing Adjustments Article Negotiating Tasks in a Project

In this episode, we get started on the implementation phase of our software product.  We have a reasonably robust design documented from the tasks of the prior episodes.  Thus, this should be an easy and natural next step.  Your product vision at this point is solid and thought through. Start Simple These first steps of implementation will be used to create our foundation and development environment.  Once this is complete, we will be ready to crank out some code and focus on our application.  Here is a short checklist of tasks we should tackle in this step. Create The Database Script any needed seed data for the DB Create the application skeleton of files (sort of a hello world) Connect to the DB and perform a query Script or define your deployment process Add the project to version control Deploy the code so far and verify it is working This process is not the most technical and will get administrative coding out of the way.  The fun part will come next. Inputs, Outputs and Happy Path The most natural path through the solution to test should be the happy path.  This is the experience a user gets when they enter all valid data, and everything works correctly.  There may be some feedback and output to verify as part of testing the application.  Thus, it makes sense to start here.  Let's make sure our solution works in at least one instance. After the happy path has been tested, then start walking down it and figure out where things can go wrong.  This will help you determine how to check input, output, and user messages or notifications.  The beautiful thing is that this provides a somewhat logical approach to testing and helps reduce the guesswork involved. Your Homework Walk through the steps and build out your foundation.  I have been building a small application along the way, and you can find that source in the file link below (tar and gzipped).  I have a few extra files floating around that are in progress and not part of this release.  However, you can actually run the ant tasks and deploy once you change the ant properties for source and target folders.  Feel free to adjust this script to your own environment to make your deployments easier. Profile Links Product - Foundational Source Code

Testing is an integral part of software development.  It is critical for producing quality and an essential habit to develop early in your career.  We will look at building test considerations into our product development process from the very beginning.  This is an excellent way to keep the cost of fixing bugs down as we will catch them early in the process when they are easier to correct. Validating Data Garbage in, garbage out is something that rises to the level of a golden rule in software.  Not only can bad data be useless on its own, but it can also corrupt and crash an entire system.  Therefore, the payoff for doing proper validation of your data and testing those validations is huge.  When you are checking validations, there are several things to consider. empty/null values exact minimum size or value exact maximum size or value one above and one below the exact minimum one above and one below the exact maximum For strings, check special characters and tags Make sure you run through these as part of checking your validations and also make sure your specification notes how to handle these situations. Inputs, Outputs and Happy Path The most natural path through the solution to test should be the happy path.  This is the experience a user gets when they enter all valid data, and everything works correctly.  There may be some feedback and output to verify as part of testing the application.  Thus, it makes sense to start here.  Let's make sure our solution works in at least one instance. After the happy path has been tested, then start walking down it and figure out where things can go wrong.  This will help you determine how to check input, output, and user messages or notifications.  The beautiful thing is that this provides a somewhat logical approach to testing and helps reduce the guesswork involved. Exceptions and Notifications The most challenging part of building your test scripts often is determining exceptions and how to notify the user when they occur.  By their very nature, exceptions are situations that are not normal or maybe even expected.  That does not mean they are always a complete surprise nor do they preclude the ability to handle them in some way.  You do not expect to cut your finger, but you still have bandages in case you need them. The trick is not only identifying exceptions.  There is also the decision to be made whether you recover from it, choose another approach, or notify the user.  When you create thorough test scripts, then these decisions should all show up in your results after a run of them. Your Homework Walk through your specification and create test scripts.  The linked document will hopefully help you with this step and provide some good experience in creating test scripts. The updated Document with Example Test Scripts/Notes: ProductCreationWorksheet-Episode4

One of the first steps once we decide to do consulting as a side-hustle is to define our service offering.  We have the option to be a general consultant and do at large coding or technical support.  However, that is not an easy one to sell or even define.  By its nature, a broad offering will limit your ability to speak directly to a customer's needs. Pick A Path Or A Few Start your offering thoughts with a favorite or ideal project to work on.  This may be something you can do with your eyes closed or what you love to do.  You may find it hard to narrow your focus to a tightly defined project.  That is ok.  Find the most specific point (or points) about an ideal project and start there.  For example, you may be happy doing any web application on Apache Tomcat and Java.  That is general enough, but also has a good enough specificity to it. Your offering, in this case, will focus on building Java web applications.  When you put together your offering you will do best if you include a few examples of websites that have varied goals.  In this case, I would have an example of an e-commerce site, a simple business site, and a membership site.  Those three examples cover a lot of common needs and show a broad range of skill application. Your Resume Your normal resume is an excellent start for this project.  However, you have narrowed your focus in the prior step.  Therefore, a tighter, shorter, more focused resume will be needed here.  There is a bit of an art to crafting a good resume in the IT world.  Most projects have multiple technologies involved and give you experience in multiple specialties. Your service-based resume needs to highlight in each project the work you did related to the service.  If you focus on Java programming then do not include work done in C# on a project.  You will want to list somewhere that you have that C# experience, but leave that out of the project details. Launch Your Website Once you have a service flyer or document and a related resume, you are ready for the website.  You might want to create the site with the technologies you focus on.  This provides yet another reference project for your customers.  That may be an approach that is too time-consuming at this point.  In that case, fire up a Wordpress site with a couple of pages to describe your offerings.  This can be done in a few hours, will be low cost, and looks professional.  Check out our video course to go all out over the period of a few weeks. Register on Work Site Your website is the home of your service offering.  Once you have that looking good, it is time to search for business.  This is easier than it ever has been.  You can create a profile on multiple sites or try your hand at a single one.  Each site is a little different in how it works, the projects offered, and the type of competition you will typically face.  Try before you buy where possible to find the best fit for you and your offering. Your Homework Now stop reading (and listening) and get started.  I have included a sample document to help you out with these steps.  However, here is what you should aim to complete this week. Create a service offering flyer/document Create a service-oriented resume Launch your website Register at a site We will hit the ground running in our next episode so make sure you have these items complete enough for your needs. Example Service Flyer: IntroFlyer Example website: https://rb-sns.com Some Site Links: https://Upwork.com https://Guru.com https://Freelancer.com https://Freeeup.com

We continue defining our product in this episode.  Our prior episodes looked at the problem to solve, the solution, and general requirements.  Now we can move on to the product specification and deciding on the environment we will use to create it. Design the application structure (core, data model, methods/functions, helpers, screens/output) Challenge: Create the specification from these decisions Choices, Choices, Choices The modern landscape provides a seemingly infinite combination of choices when we consider languages, data stores, platforms, delivery method, and the other variations available to a solution.  There are several things to consider in making this decision. Languages you know (or want to learn) A Suitable platform for your customers The cost to you and thus customers Speed and reliability Maintainability It may appear that there is no single answer to this decision.  That is correct.  The decision may make the solution better or worse to create and deliver.  However, there are many reasons you may choose a path that is not the easiest nor even the most obvious. The Data Model The specification can start from the data or the user experience.  In any case, at some point the data you will capture and manipulate needs to be nailed down.  When you are building out your model there are several things to consider. Core data properties: What data do I need? Data types: Is this a string, a number, a formatted value (phone number, zip code, street address, etc.)? Data relations: How will I report on this data and do I need to link core data facets to each other?  If so, then what data will be used to make that link? Lookup data: Where do I need to provide a list of values for a data value?  Common examples are state names, titles, status values, and more. Seed Data: What data do I need to create in order for the application to be useful?  Do I need to seed a master account profile or type values? Audit: Do I need to be able to track changes to the data?  If so, then at what level and how much detail is needed? The User Experience The other key piece of a specification is essentially the user experience.  This includes the look-and-feel specification.  However, that is just the tip of the iceberg.  The navigation options and locations need to be thought through.  The way that notifications and system messages are displayed is another key part of the application interface.  This also includes system level interfaces like logging to a file or database. This is where you will specify the screens and flow of the application.  These pieces are key to the specification because they will often constrain the way it will be implemented.  When these are not properly specified it increases the risk of coding yourself into a corner. Your Homework Your homework this time around is to create your product specification.  You should be able to knock it out in less than an hour.  Also, you are welcome to send an email to us for feedback or suggestions to help you along.  I have been building a product along the way and you can see my product specification in the document below.  Feel free to use it as a starting point or to give you some ideas on how to approach yours. ProductCreationWorksheet-Episode3

In this episode, we look at creating the product requirements for our side hustle software.  Even though we have a lot of this information in our head, it is good practice to put it on paper.  This exercise will help us think through our plan more thoroughly before we begin.  It will also give us another experience in building out product requirements on our journey to become better developers. The Users It helps to think about the end users from the start.  This is the audience for your product and the ultimate deciders whether this is a success or not.  You can stay broad in your definition.  However, the more specific you can make your ideal users the better your product will be able to appeal to them.  The problem you are solving should be one that the perfect user cares about.  This may be obvious as they have to care enough about the solution to pay money for it. The Solution Once you have the vision of the users set then look at the problem and solution.  Is this a one-time problem like migrating data to a new product, a daily problem like checking the weather, or something in-between?  How will your users want to access the product?  When you have thought about these questions, then you are on your way to defining the approach your product needs to take.  This is where you make decisions about whether it is a desktop application or a phone app. The Core Now that we have a very rough idea of our solution we can document a rough idea of how it will look.  We can build some wireframes for the main page or pages.  The key features can also be described at this time.  We will go into specifications in the next episode for now.  Thus, think about this step as creating a form of an outline of the solution that includes some screen ideas as well as those important features or steps of the solution. Your Homework Add to your current document.  Add some sections that detail the decisions made as to the perfect customer and your approach.  Then start building out your requirements.  Good luck. ProductCreationWorksheet-Episode2

This episode kicks off a new season focused on how to launch your online consulting side hustle.  The weekly episodes will walk you through making a plan, creating marketing materials, landing a customer, and then repeat business.  Time to get started. Set Your Online Consulting Goals Any good business starts with a vision.  You need to take this step even with your side hustle.  Consider your goals, maybe even a vision statement for your side hustle.  Your intentions may be to learn more skills, earn some extra income, or tackle a broader range of projects.  All of these are reasonable goals and will help you decide what customers are the best fit for you.  Customers do not just choose you.  Your goals should always be in the mix of whether you are a good fit for a project. Do not be afraid to be time and money focused.  If your goals are to make another $500 per month, then include that in your planning.  Your "why" can be anything you desire.  Therefore, be true to yourself during this step.  You will be happier for it in the long run. Plan Your Approach There are many ways to find work and offer services in this market.  Consider what will work best for you.  Your offering can be maintenance or staff augmentation coding, software product creation, technical assessment, or other areas.  Much like your goals, the approach you desire will profoundly impact the customers that are the best for your online consulting work. Define Your Target Market Your goals and approach will have a lot to do with the projects and work that is best suited for you.  However, you will also need to determine the target market you want to address.  Your situation may be perfect to help start-ups or small companies; it may be better with mid-sized companies.  Alternatively, your work may be best in an industry like shipping, banking, healthcare, or other niches. Level of Effort Finally, consider how much work you want to do.  Your daily schedule will often be a starting point for the time available to your side hustle.  However, your drive may help you target a substantial level of effort.  The measure of your energy will often be hours available.  Thus, a plan for ten hours of work per week would be a good target.  On the other hand, you might have days off you can use for online consulting.  In that case, you can target those days per week. Add up the time available to get a weekly or monthly availability.  This will be important when applying for projects.  For this week, go ahead and create a brief document of your side hustle business plan to get yourself started.