Develpreneur: Become a Better Developer and Entrepreneur

We all have started our professional life with that most challenging obstacle in front of us, experience.  I think all of us have experienced the challenge of getting experience when every job seems to require it.  This common chicken-or-egg situation is not hopeless.  We can put together a compelling case even when we have minimal experience in specific areas or skills. Minimal Experience or None At All When we have limited or zero experience in the desired area, we have to get creative.  Our best chance of winning these positions is through complementary skills.  Remember that most IT positions are aimed at solving problems.  When you dig into the problem to be solved, you can find some options for getting there with different experiences.  For example, an entry-level PHP job may involve building a web application.  In that case, you can highlight HTML, CSS, or Javascript skills as a way to be productive while mastering PHP.  This situation is common, so make sure to highlight skills that are used across several platforms, including database work, web applications, mobile applications, and industry exposure.  An exact fit is not always feasible or even the best fit for a position.  Sometimes thinking outside of the box will allow for the best person for a job. Detailing Your Experience When you start your career or with new technology, experience may be thin.  It is ok to take a class you attended or side project you worked on and include it in your resume.  You also can add detail to make a little experience more appealing.  Rather than a short line item that you worked on a project using technology X, provide information on the problem(s) you solved.  You can get too far in the weeds.  However, if you give a short description of the project and how you used the technology, it can be impressive.  You might even be able to show a better grasp of utilizing the technology than someone with more experience.  A little selling never hurts. Avoid Dishonesty Above all, do not put in details or experience that you do not have.  This path is most alluring when we think we lack experience.  However, it is never good to use dishonesty to win a job or project.  You are more likely to fail and generally be unhappy along with the risk of being seen as untrustworthy.  That is a lose-lose situation every time.  If nothing else, the challenge of selling your resume when it is thin is an excellent learning experience.  That can be a huge benefit when you get to a point where your resume is full of rich experience.

We kick off the new season on career improvement with an episode to set the table.  We take a look at what we will cover and how our attitude can drive success. Our path is not always easy.  However, it should be enjoyable.  When you are unhappy at your job, it is time to look elsewhere.  There is no need to be miserable. Both Sides of The Table This season will look at several topics from both the hiring and prospective hire views.  Communication with our boss, coworkers, and staff is critical.  Thus, insight into how "the others" live and view jobs can help us all.  We will use multiple viewpoints and seasons of a career throughout this season in the hope that everyone gets something out of it. Career Improvement and Self Satisfaction There are many ways to "keep score" in our careers.  The primary method should be happiness or enjoyment.  When it is not, all of the other rewards will tend to fade.  Money and respect can be excellent.  Nevertheless, I subscribe to the old idea that happiness is worth more than any amount of money.  If you have a different view, that is ok; I want to be clear on what my typical focus is in case you weigh options differently. Experience Rules We will be looking at many ways to improve how you are seen and highlight strengths.  However, our goal is not to fool people.  Instead, we are selling a product we believe in (ourselves) and trying to find win-win scenarios.  Our best job is the one where we are happy and highly valuable to our employer.  The challenge is finding out where that is and then winning the offer.  Thus, our experience and skills are tantamount.  Whether we consult, are employed, or work a side hustle, we need to be able to follow through on the jobs we take on.

As we reach a milestone episode number (350), it is a good time for us to look closer at milestones.  These project management tools may appear to be tags or labels along our path.  However, they are more than that and are a valuable way to drive us through to completion.  Also, they can be points in time that allow us to take a step back and ensure we are still on track. Milestones can be a clean start One of the best values of a milestone is that it allows us to define a before and after.  We can often get a fresh start as we pass one of these points.  Nearly everyone embraces this fact.  Even when we do not recognize it as such.  The most famous of these situations is a new year.  That is a milestone at its heart and one we often use to put the past behind us and focus on the future.  This step can relieve stress as well as provide us a pivot to become better. Providing a Narrow Focus A well-designed milestone gives us a narrow focus for a while.  We drive our actions to progress towards the goal.  Likewise, we have an excuse to ignore the tasks that do not contribute to that goal.  This process allows us to avoid distractions as well as make them more visible.  For example, A goal to earn a C# certification makes it easy for us to skip reading the latest Java news.  Our focus is elsewhere, so that distraction is easy to identify for what it is. Building and Pivoting That natural pause that milestones provide gives us many benefits.  These include the list below. We can build on a milestone.  It provides a concrete deliverable that can be critical for advancement. It is an excellent time to pivot.  We have arrived at a point where it is probably cleanest to change directions or correct our course. A celebration never hurts.  We should at least take a moment to revel in our success.  We have accomplished a goal, and that is worthy of a little celebration. We have looked at how to use pauses and whitespace to add flavor and productivity.  Why not utilize these natural pause points to our advantage?

We spend a lot of time talking about planning and setting schedules.  This activity is a necessary process.  However, we should learn from our past and adapt our schedule when possible.  There is no sense in scheduling ourselves into an unworkable schedule.  Sometimes a few schedule adjustments make the difference between glorious success and burnout. All Plans Go Out The Window In Reality There is a quote that says plans are worthless, but planning invaluable.  This simple truth is important for us to take to heart.  We can plan all day long to achieve an impressive number of goals.  However, planning and doing are not the same.  Life happens, and that can throw off even the best plans.  We also may find that tasks look better on paper than they do in reality.  For example, sleeping four hours a night and completing a lot of goals looks appealing.  However, we may end up utterly exhausted or find we have ignored critical things like our health or family. Incremental Improvement Via Schedule Adjustments Think about your weekly plans as an estimation exercise.  You may find that some of the items on your list get done faster than you thought.  On the other hand, some will take more time or effort than suspected.  With that in mind, you should find it perfectly logical to periodically adjust your schedule and plans.  You can do this weekly as you start into a new season of tasks and chores.  For example, it makes sense to start your year with weekly reviews of how you did since we tend to make a lot of changes as part of the new year.  These schedule adjustments will help keep you sane and might even improve the success rate you have with resolutions. Quality over Quantity In my experience, a common problem with goal-setting is putting too much into the pot.  There are limits to the value we can give to each item and may get to a point where we are mostly just spinning our wheels on too many things.  Warren Buffett has a 20-slot rule that he refers to in investing, but the concept works for goals as well.  We have a limited number of goals we can effectively work on at a given time.  It makes sense to reduce the number of goals and improve our quality of progress. https://jamesclear.com/buffett-slots

We all make mistakes.  Even our best intentions can lead to errors.  Thus, we can make best practice mistakes.  While this may seem like an impossible situation, you will soon see that it is common.  Knowing the recommended approach does not mean we will follow it nor even that we should. Rules Are Meant To Be Broken The first thing to consider in avoiding best practice mistakes is whether your situation is applicable.  There are extreme examples like knowing to wait thirty minutes after eating before swimming is no help in designing software.  We need to apply these wise recommendations properly.  The challenge comes when we are asked to determine whether a technology best practice should apply to our specific solution. A better technical example is the idea of data normalization.  It can be argued that the highest normal form is best.  The amount of storage space required is reduced, and caching may be more manageable.  However, you will find that high levels of normalization lead to more table joins in your queries.  In case you have limited join experience, the more joins in a query, the slower it will run.  Modern database engines tend to be able to handle a few tables in a join, but once you get to high single-digit numbers of tables, it slows to a crawl. With that in mind, we can agree that any best practice should be seen as a recommendation instead of a hard and fast rule.  Therefore, we can pick and choose how closely we follow a recommendation.  We need to be clear on why we ignore one point while using another. General vs. Specific In the world of technology, we often see best practice mistakes related to generalities.  It is important to remember that best practice recommendations are usually aimed at general software development.  Your situation may not apply.  Realtime and other processing-intensive applications can fall into this category.  The flexibility we often desire from software has a cost.  When your first goal is speed, flexibility is not worth that cost. Know the "Why" Ah, yes, we see this again.  The "why" of a problem, a solution, and even an application is always essential for our success.  That is why (no pun intended) we need to examine best practices with an eye towards whether each recommendation is one that applies in our situation.  While it would be easy for us to follow them blindly, it would also be foolish.

Urban legends cover a broad range of topics and often have a feel of being correct, even when they are not.  This phenomenon is not restricted to saying "Beetle Juice" three times.  There are all sorts of urban legends that we run into, and they extend into the world of best practices.  These examples feel like they are the right thing to do, but may even be the opposite. The Foolishness of Crowds Many of the problems with best practices devolving into urban legends territory seem to be rooted in groupthink.  We do not always speak our minds, nor do we question enough.  When we are worried about looking foolish, silence is often the path to take.  However, this can cause all manner of issues when combined with communication challenges.  Therefore, regular sanity checks of our processes are critical to keeping them on track. The Telephone Game Communication is easy to confuse.  It speaks volumes that the old playground telephone game is also known as "Chinese whispers."  Chinese may be easier to understand than the confusion that often comes out of this little past time.  The essential point of the game is that every point of communication is also a potential point of failure.  This weakness can even impact our best practices.  The documentation and dissemination of those practices may not be perfect.  That can lead to all manner of confusion over time.  Thus, urban legends around our best practices may be the culmination of a series of minor miscommunications. Back To Basics The path to better best practices and avoiding urban legends is through regular reviews.  We do not need to question everything all the time.  However, we should question everything periodically.  If for no other reason than to ensure we are all agreed on what our best practices are.  Technology is changing our world every day.  It is time to ensure our best practices keep pace with all of the latest advances.

Software developers and designers are often asked for a recommendation to approach a solution.  The implication is that we know the right decision.  We often join in on this assumption and will debate or argue that our way is the best option.  While there may be a "best approach" to our problems, it is worth digging deeper into the costs associated with the right decision. Arguing For The Right Decision The first hurdle to overcome in assessing cost is debating the options.  When there is a clear-cut approach that is the best one, then we can often decide and move on.  On the other hand, there are more often going to be a few solutions that are similar, and a clear winner is not apparent.  The time and effort spent debating and buttressing the options can become lengthy and even expensive.  When the difference between the options is minimal, it may be best to choose one and move on.  Hesitation alone can be costly. A Changing Environment We have looked at numerous situations where the best decision today is not as good tomorrow.  We live in a world that is constantly changing.  Likewise, new products and features turn up every day.  That also is a reason to avoid splitting hairs in our desire to find the best solution.  Those key indicators that make one solution the best can be unimportant by the time we implement.  The more granular our focus on the arguments we make, the more likely our decision will be impacted by changes in the landscape. Progress Over Planning You can refer back to the Pareto Principle as an argument for making a decision sooner rather than later.  The thought here is that the parts of the project that distinguish those similar solutions are going to live in that final 20 percent.  In some cases, we may not even get that far into the solution in our first version.  While we want to avoid decisions that may cause obstacles down the road. Sometimes multiple paths will lead to the same destination.

It is time to end another season.  At this point, we need to revisit the idea of software architecture deliverables.  In particular, we should spend some time thinking about how we communicate our architecture. Multiple Audiences for Software Architecture Deliverables First and foremost, there are a couple of levels of audiences that your deliverables will need to address.  This situation is always one of the most challenging to handle correctly.  Fortunately, we have other types of documents to learn from.  We can look to similar deliverables like an RFP (or response to an RFP) for a structure and approach that makes sense. A Tiered Response Our prior discussions have covered this sort of "tiered response" or communication.  We can craft a series of sections to communicate a growing level of detail.  Therefore, we start with a summary, then move into core details, and finally supporting documentation.  In this case, those sections cover executives, then implementors, and then architects or assessors of our work. The sections of the software architecture deliverables should flow nicely into the areas we want to address.  The summary addresses significant decisions and the overall environment.  We then move into the actual architecture.  This section is often the most substantial part of our deliverables and critical for proper implementation.  We can provide an addendum or an appendix to address the "backstory" of our architecture and details about our thought processes behind the design. Focus on The Varied Questions The critical facet of each section we have mentioned is how we address questions for the target audience.  These issues should be treated as part of creating our deliverables.  For example, managers and executives are going to need some points they can share with others about the general structure and platform.  The implementation team is going to need detailed descriptions of how the provided architecture should be implemented.  They will want to see how all the pieces go together and how to build each piece.  Those that come after you will want to know what options were considered, why you chose what you chose, and paths that were willfully ignored.

It is time to wrap up the season of software architecture from scratch.  We have covered a broad range of topics and now are able to look over them as a whole.  There are common themes across the various areas that point us to software architecture best practices.  Here are a few core concepts we should take from this season. Clarity is Key We have to communicate our results.  These deliverables are essential in making our work valuable.  Think about it, even the best architectural design is useless if it can not be implemented.  When we fail to properly communicate our ideas, we reduce the likelihood of successful implementation.  Therefore, pay attention to the details and note them in your deliverables.  Likewise, provide some reasoning behind your decisions.  A sort of historical record of your thought processes is invaluable to future architects.  The world is constantly changing.  Therefore, your architecture will be reviewed with an eye towards what needs to change.  Your notes and "color commentary" can help speed the review by those down the road. Validate The Architecture A common newbie mistake is to build an architecture from an "ivory tower."  Thus, the result is an academic masterpiece.  However, it is not viable in the real world.  We all know of concepts that look good on paper, but pale when we move into implementation.  Every bit of the architecture that fails to be viable will reduce the faith in all of the work.  It is best to avoid these confidence killers and instead validate your assumptions where possible.  Yes, this may require a proof-of-concept or similar demo.  On the other hand, your comfort in your assumptions will be worth the effort. A Place For Everything We sometimes get carried away with our architecture.  This situation is particularly common when requirements change while we are working through architectural tasks.  We may create a piece that is not needed or may forget to connect together some of the pieces.  That means we need to do a final review of our architecture against the requirements before we wrap it up.  Even a short amount of time can highlight blatant gaps we left in our design amongst the hectic schedule of changes.  Sometimes the software architecture best practices amount to simply checking our work.  

We have looked at a broad range of topics this season.  However, it is time for us to tackle the middle tier architecture.  Thus, we need to consider process steps (or flow) and look for commonality among the problems we solve.  This area is not the most obvious to architect.  However, it is an essential piece of the final solution. Middle Tier Architecture As We Go One of the challenges with the middle tier architecture is that it tends to get built over time.  We design the front and back ends of the application.  However, little time is spent on business rules and core logic.  Data items and visual controls are more concrete for us to work with.  The logic and problem-solving that makes up most of the middle tier tend to be nebulous. While that "squishy-ness" of the middle tier can be a challenge, I do not think we avoid that architecture.  It just tends to be less noticeable.  Of course, once you start to dig into the business logic, you will see all manner of pieces that can be used to build out an architecture. Your Personal Framework Generally speaking, the middle tier architecture is a framework for your solution.  This area often contains the heart of the solution, and many of the critical problems solved for your users.  When you think about it, the front end displays your solution; the back end stores it, and then the middle is where the work gets done.  That alone should get you thinking that more time should be spent focused on the design and architecture of the middle layer.  When you do things right, the resulting solution may be viable to spin off as a commercial product. Avoid Duplication The best outcome of middle-tier architecture is the avoidance of duplicate code.  That is what typically happens when we allow this tier to grow organically.  It is not until we see a lot of repeated code that we step back and refactor.   That is a costly approach in time and effort, so it is worthwhile to plan and avoid this situation.