Develpreneur: Become a Better Developer and Entrepreneur

We continue our discussion with Timothy Stratton with a dive into continuing education and how to keep up in the fast-moving world.  There are always job responsibilities to address that keep our time at a premium.  We talk about finding ways to stay up-to-date and the cost of this career path. The Cost of Continuing Education Let's start with the bad news.  There are only so many hours in the day, and that means we have to trade off other pursuits for our careers.  However, it is not all bad.  The things that Timothy mentions as giving up can always be reviewed later.  You may not watch as much television or go to the movies, but you can do that later in life.  That is the price you pay when your career is starting and time is at a premium.  Trust me.  I went years without keeping up with current TV and movies and then was able to catch up as desired once life got less hectic. Constant Reader One of the most important requirements for continuing education is reading.  Whether it is books, journals, blogs, or news sites, most of the best content must be read.  There are excellent podcasts and similar outlets.  However, most of what we need to keep current is communicated better through reading rather than listening.  That means we should expect to read a lot and fit it into our regular schedule of tasks.  Fortunately, digital delivery allows us to take and consume this content anywhere. Our continuing education effort can become part of shopping for groceries, waiting in line for a meal, or kicking back on our porch.  We can convert any part of life into a classroom.  However, do this in moderation.  We still need to be able to find some semblance of balance with our personal lives. A Little Background Timothy is a software development manager at XSolis with a strong development background.  He has a master's degree and a love for learning.  We gave some details in part one and then dug deeper into how his career started and how those steps led to success today in part 2. Contacting Timothy You can send an email to info@develpreneur.com for other methods of connection. Unfortunately (for us), he is not a fan of social sites.  Thus, he keeps that footprint small.  However, he is happy to help others, and we can connect you through any of the normal Develpreneur avenues.

Part two of our series of interviews with Timothy Stratton looks at his early years.  He started with a focus on higher education.  That worked well for him, but not directly because of his studies.  We explore how the journey taught him more than the academic focus. A Little Background Timothy is a software development manager at XSolis with a strong development background.  He has a master's degree and a love for learning.  We gave some details in part one, but dig deeper into how his career started and how those steps lead to success today. Higher Education Side Effects The value of a degree is often noted as coming from the work done more than the learning itself.  Timothy is no different and gained many valuable skills while working on his Master's degree.  These rewards came in some surprising areas like communicating to team members and thinking through details.  He still is gaining from those years in academia and even continues to review his book from those times. Clear and Concise We spend time talking about learning and communicating.  These are two activities that we should not ignore.  They are recurring themes for success as we look at those that have model careers.  Our world of technology changes too fast to sit back on prior knowledge.  Likewise, we must be able to share and convey that knowledge for it to be beneficial.  We can not be successful if we live in an Ivory tower of knowledge where we do not use and transfer it to others. Great Links for more From Timothy You can send an email to info@develpreneur.com for other methods of connection. Unfortunately (for us), he is not a fan of social sites.  Thus, he keeps that footprint small.  However, he is happy to help others, and we can connect you through any of the normal Develpreneur avenues.

We start the next interview with an introduction to Timothy Stratton.  He is an experienced developer moving into a role as a manager.  This episode focuses on starting a new project and how to ramp up to new technologies. A Little Background Timothy is a software development manager at XSolis with a strong development background.  He has a master's degree and a love for learning.  We will cover those in the interview, so no spoilers here. Starting A New Project We often have a new project to start.  That can be a new job, a new product, or learning a new language.  In each of these cases, we must first plot a path to go from little or no knowledge to enough to get us started.  Documentation is invaluable in these situations.  However, it is not always available or thorough.  We can supplement documentation with questions and discussions.  That includes shadowing users or subject matter experts.  Thus, sometimes watching others is the best way to help us discover what we do not know. A picture is said to be worth a thousand words.  That is important to remember when learning a new thing.  Likewise, we can learn quickly by seeing someone in action rather than describing it.  For example, consider learning to tie a shoe through an example as opposed to a how-to document. A Hidden Gem When you are faced with a confusing new environment, ask questions. Of course, you are not expected to know everything, and the easiest way to get answers is to ask questions.  Nevertheless, we skimmed right through that gem in the interview, so please do not let it go by without note.  This is the best technique for getting started quickly.  Therefore, embrace your inquisitive side and speed your learning through questions. Great Links for more From Timothy Look him up on Linked In to connect.  You can find him at Timothy Stratton.  You can also send an email to info@develpreneur.com for other methods of connection.  He is not a fan of social sites.  Thus, he keeps that footprint small.

The second part of our interviews with Trevor Ewen focuses on the value of a technical MBA.  We discuss the benefits of the degree, the program, and the network it can build.  This discussion is a must for those that are considering taking that step. A Little Background Trevor is an experienced software engineer, project manager, and real estate investor. He has overseen full-stack teams in clean energy, insurance, finance, and media. Notable engagements include Morgan Stanley, HBO, Bloomberg, Honest Buildings (now Procore), RunEnergy, Black Bear Energy, and PRco USA. He has an MBA from London Business School and Columbia Business School via the joint, global program. The Value Of A Technical MBA An MBA is not always an obvious (or even desirable) path for someone with a technical background. Nevertheless, there is a lot worth considering when the opportunity arises.  Our discussion touches on the paper value of an MBA as a resume tool.  There is also a level of expectation it can bring to potential employers. First, however, we spend more time looking into the process itself and how it can provide an excellent learning experience. An advanced degree program can put us in the company of like-minded individuals with varied backgrounds.  That is a recipe for expanding horizons and creating a valuable network of friends and go-getters. However, if we are defined by the crowd we hang out with, how much better can we do for our careers? A Hidden Gem A key point to take away from this conversation is that building software can be done with more than just code.  There are libraries and resources to help you reach a solution quickly and without starting from scratch. Great Links for more From Trevor https://stg.software trevorewen.com

We wrap up the Trevor Ewen interview series with a discussion of building libraries and extending code.  While this is often a necessity, there are different ways it can be done to help separate your code from the core or to safely build on it.  Your desired approach will vary by application and the customers involved. Extending Code Safely There is often a right way and a wrong way to extend code.  We need to do this in a way that allows us to incorporate updates to the foundational source and not break our extensions.  It is also helpful to refactor extensions into using core functionality as libraries evolve.  Every tool and platform handles these "hooks" differently.  Therefore, we need to understand the core and our customization impact before we integrate things either too loosely or tightly. Supporting Your Work The other key consideration in building an extension or library is support.  Licensing may be an issue, but support and maintenance will always be a factor.  You are not committing to a solution for only today.  The solution needs to survive in the future and handle upgrades and fixes without falling to pieces.  A one-and-done library is not worth the effort.  When you plan on extending code, you also should plan for keeping that extension useful over time.  That is the same whether you build an internal library or are selling commercial software. Great Links for more From Trevor I had a great time doing this interview and reviewing the content during the editing process.  It is my hope that you got as much or more out of it.  Feel free to send questions (or business) to Trevor.  The links below cover what he shared in the audio so you do not have to take notes. https://stg.software trevorewen.com

The third of our series of discussion episodes with Trevor Ewen touches on a functional core and imperative shell.  This is an approach to building software that uses a strong core to extend to custom solutions.  We provide some options for building on your previous solutions in the modern world of software frameworks, libraries, and open-source. Functional Core The underlying theme in this approach is a functional core.  You want to craft a foundation that is solid and extensible to speed future development.  That does not mean maximizing code reuse as much as it does solution reuse. Instead, we focus on delivering a solution quickly and reliably with less worry about maintenance.  Thus, we can build quickly and worry about refining our solution for reuse after it has been delivered. As a result, we get speedy delivery, and eventually, we will see reuse where needed.  This process allows us to avoid designing code for reuse that is never used again. When To Share We wrap up this episode with a discussion about timing.  There is a level of "baking in" that is useful before converting code to a library or sharing it with diverse projects.  Yes, we can always design all code to be shared.  However, some solutions are too niche or customized to be useful outside of the original solution.  We want to find a reason to share code other than "because we can."  That means we need to keep an eye out for how often we see similar problems or use existing code snippets to jumpstart a solution. Great Links for more From Trevor https://stg.software trevorewen.com

We start a new season of episodes full of interviews in a discussion with Trevor Ewen.  Building software is an underlying theme of this part of our multi-part series of discussions with him.  This also includes the introduction to Trevor and a setup for part 2. A Little Background Trevor is an experienced software engineer, project manager, and real estate investor. He has overseen full-stack teams in clean energy, insurance, finance, and media. Notable engagements include Morgan Stanley, HBO, Bloomberg, Honest Buildings (now Procore), RunEnergy, Black Bear Energy, and PRco USA. He has an MBA from London Business School and Columbia Business School via the joint, global program. A Rich Environment For Building Software A key point to take away from this conversation is that building software can be done with more configuration and less construction.  The world is full of SAAS products that can get us to a solution quickly and reliably without breaking the bank.  These low-risk options may be exactly what you need to jumpstart your idea into a business or enterprise. The recent job market downturn has also forced many excellent developers to look for a new job or into consulting.  That can translate into finding resources to "rent" when you have a difficult hurdle to overcome or maybe long-term resources at a bit of a discount.  Of course, you never want to low-ball an employee, but you may find some deals out there. Great Links for more From Trevor https://stg.software trevorewen.com

We wrap up the season with a focus on the design process.  There is a cost to doing this, as with most things of value.  However, you will find that the benefits in tighter, easier to maintain, and higher quality code are worth the investment.  We can use the tools and frameworks we have to take shortcuts to an object-oriented solution or be better by spending time on design. Object-Oriented Design Is A Revision We have discussed how the solution is always our primary focus.  Developers solve problems.  Therefore, our "why" is crafting a solution.  The emphasis is on the solution not on the craft.  Once we have a solution we are comfortable with, then we can look to mold it into something better.  Therein lies the rub.  We have a solution so we could push forward to implementation.  On the other hand, we can spend time refining the solution.  The wise developer chooses the latter approach. The Design Process Is An Investment There is no question that design time is an investment in our implementation.  A brute-force approach is often an option.  However, those solutions rarely hold up over time.  Even duct tape has its limits.  Thus, time spent on design assumes we will be able to make up that time in future endeavors to maintain, scale, or enhance our implementation.  That makes efficiency and clarity the primary goals for our design process.  We want to craft code that is worth re-use and that can handle relying on it for bigger and better things than this one solution. Stopping When Needed We also are going on hiatus for a while with the podcast.  This is going to be our last episode until further notice.  It does point to the value of making decisions and acting once a decision is made rather than some arbitrary time frame.  We often talk about goals and regular reviews of our plans.  However, sometimes it is best to act sooner rather than later.  That can help us avoid investing in things that we see of lesser value.

Software developers are known for many traits.  Unfortunately, one of those is ignoring the keep it simple philosophy.  We tend to "show off" our prowess through complex designs and implementations.  However, those rarely are the best ones in terms of maintainability and even performance.  Simplicity has its benefits. Keep It Simple - Direct Is Better While there is a value in the "scenic route" when we are out for a leisurely drive, it is not the most effective way to travel.  The same concept applies to our designs and solutions.  The direct solution is often the best, even though it may sacrifice scalability or its ability to be applied in a general fashion.  When we focus on highlighting our design skills, we often end up with a solution looking for a problem.  That is not a mindset that servers our customers. Solve The Problem First Therefore, we should always start our design with a focus on the problem.  The starting point should be the solution and then map that to an object-oriented design.  If we focus on the OOD, we may inadvertently attempt to cram a square peg in a round hole.  This thought takes us back to the agile manifesto.  The number one goal of our solution should satisfy the customer.  While a solid design is valuable, it is a means to an end, not the end itself. Opportunity-Based Design When we start with a solution and then translate it to an object-oriented form, we are taking advantage of opportunities.  There are opportunities to improve our solution through OOD.  A good design makes use of these.  Thus, our solution dictates where OOD may be useful.  We can take advantage of those without using all of the features OOD provides us.  It is like many things in life.  Just because we can does not equate to "we should."  For example,  our car can go faster than the speed limit.  However, there are many cases and reasons not to push the car beyond that limit.

An often overlooked facet of object-oriented design is how to leverage your language to speed development.  Every coding language has features and strengths to make your design or implementation better.  We should not design to a language initially.  However, we can tailor our implementation and detailed design to take advantage of these features. Leverage Your Language to Boost The Implementation Languages are implementation tools. Therefore, they come into play during that phase.  Nevertheless, you can leverage your language as you consider the details of the design.  Some approaches will either be simple or complex based on the language.  We can include the concept of interfaces or multiple-inheritance in a hierarchy.  That includes more granular steps like patterns built into the language.  We often see these in the form of iterators or factories. Keep Up With Changes While the initial design should leverage your language, enhancements and upgrades should incorporate the same.  Be aware of the changes to a language or environment over time.  That includes fixes, tweaks, and new versions.  A problem that may have been overly complex to solve in the past could be a "freebie" solution now that it is handled in a single line of code. Languages evolve and often do so with a focus on eliminating weaknesses.  That is due to developers suggesting features based on their pain points.  We often see a language that is limited in use during early versions become more general-purpose over time.  The developer is the customer, so the software team or company will cater to the developers.  The things that are difficult to use early on will be simplified or greater support provided. Under The Covers The changes to be aware of include those that are "under the covers."  These types of changes are much more implementation-impacting.  However, version upgrades have been known to make vast improvements in persistence, multi-threading, and thread-safety.