In 1980, I attended a 3-month course at the Center for Computer Education in Lynnfield and was taught “Structured COBOL programming”. I then worked for the Commonwealth of Massachusetts Department of Welfare for 4 years, using COBOL as my first programming language. I had no real mentors here but did make a number of long-term friends. The lack of a mentor made it hard for me to progress as much as I did later in my career, where I had the advantage of working with some really smart people, so it is good that I learned to love computers early on at this job. I was pretty self-directed. Towards the end of my time at this job, I was able to work with some PL/I consultants who showed me what a “real” programming language was like. With this new knowledge, I was able to change jobs, and to double my salary first at MGH, and then at SEI corporation.

Around this time, I attended a course in PASCAL at UMASS Boston, and a PL/I course at Boston University. These jobs had people who were able to teach me some new tricks, but I also was able to return the favor to them. This lack of mentorship in my early years I look back on as a benefit. I was really “thrown into the deep end” in many places, which really helped me to keep learning as much as I could on my own. If I hadn’t continued to love computing, I would have certainly left my career in its early years.

I really didn’t get “Mentored” until I became a consultant, taught myself C and the Windows 3.1 SDK, and went to work at MIT. Through my consulting years, I worked at 10 to 15 companies, doing Windows UI development and SQL database work. These positions were both enterprise-level and desktop-level. There were about a half dozen people I considered mentors at these assignments, and I also sometimes acted in a mentor role to more junior employees.

I think it was fortunate that I was able to work at so many diverse organizations, because I became familiar with many new programming languages and software products, as well as obtaining a broad view of many diverse industries.

So, starting with COBOL, which I look back on and realize was a terrible language, I entered a journey which would continue to get more and more interesting as time went on. I have programmed in C, C++, C#.NET, PL/I, SQL, and a few others, but didn’t really feel I had found “The Language” for me until I started developing with Java which allowed me to convert to mobile Android development.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

I am combining these two patterns because I think that one without the other will make for an improper balance of skills. This quote [1] by Carl Rogers in his book, on Becoming a Person [2] is very inspirational to me. I have made a career habit out of trying to be unique, self-directed, and perform self-directed learning.

I am also aware of the importance of being able to admit gaps in my knowledge to others. I will be the first to admit that I don’t understand something, or that someone else has a better idea than I do, especially when I think I can leverage this knowledge to improving my skills, and my personal development efforts.

Throughout my career, I have always had home-based software projects in play. The two most noticeable were Guitar Companion, (a Windows C++/MFC turned C#.NET utility program for guitarists which contained components for a notation editor, metronome, tuning fork, band manager, and video guitar lessons), and Guitar Chords, an Android app using MIDI, speech recognition, and swiping techniques to display an intuitive, pleasant looking, and efficient way to show and play any chord.

Although these efforts didn’t make huge sums of money, they did have the intended benefit of ramping up my skills in different areas, allowing me to learn from my home office, and then use this knowledge when needed at companies I worked for. The reverse effect also occurred. I was able to learn techniques at client sites, and then parlay this knowledge back to my personal efforts.

If I had not been willing to “expose my ignorance”, I would not have been able to learn many techniques from other developers. If I had been too focused on “confronting my ignorance”, I would not have done well at sharing back the knowledge I had attained on my own. This process was truly a win-win experience.

It is beneficial that as one grows in their career, they become progressively less concerned about others thinking they are not adequately qualified, because they have gained enough information to both learn and teach. This will lead to salary increases, better projects, better interviews, better companies, and ultimately to a happier career.

References:

1.“If we value independence, if we are disturbed by the growing conformity of knowledge, of values, of attitudes, which our present system induces, then we may wish to set up conditions of learning which make for uniqueness, for self-direction, and for self-initiated learning.”

2. Chicago. Rogers, Carl R. 1995. On Becoming a Person. 2nd ed. Boston, MA: Houghton Mifflin (Trade).

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

This sprint ran more smoothly than Sprint 1 did. As a result of having obtained a more detailed specification by coordinating with the goals laid out by Dr. Burge from Nassau Community College and having obtained a better understanding of the individual skill-sets of our team members, we were able to produce an OpenAPI specification that defined 8 of the 9 requested endpoint definitions. The yaml file containing these definitions was then used to write, build, and test these endpoints in our back-end container. These methods were then tested internally within the container by using the Visual Studio Code environment to launch HTTP requests from 2 files (guest.http and qs.http). “Swagger UI” was used as a VSCode extension to facilitate this process.

It was easier this sprint to distribute work among the team, because the Open-API spec was available shortly after the start of the sprint, enabling back-end code to be written and unit tested. As testing progressed, we would modify the spec as we made changes to the back-end code to fix bugs.

Although we did a better job at keeping the Git-lab Epics and Issues boards properly in place than in the prior sprint, this may have been the weakest area of our efforts. Our intention is to improve the ongoing modification of this Scrum material as we progress to sprint 3.

We improved our use and efficiency of GIT to Git-Lab coordination, were able to build semantic versioning, checked the structure of the Open-API definition with Swagger Preview, and started looking into using a secure key. This key will be coordinated as a priority in the sprint 3 effort through communication with the IAM team.

I was able to set up a fork of the NEST Android application with the intention of doing system testing of the REST API. By using Android Studio, my prior knowledge of Android development with Java, and the help of a guiding YouTube video, along with general help from stackoverflow.com community, I was able to write 6 classes in an isolated namespace to the project. This code uses an android library call Volley to facilitate REST API development. This code launches an activity from the main NEST activity which allows the user to make requests to the remote back-end MongoDB database, and returns responses, which are then displayed in a scroll-able text view component.

The layout used by this activity used a relatively new UI component called a Constraint Layout, which improves the efficiency and maintainability of its XML code with the support of a sophisticated design tool allowing “drag and drop” of components, allowing them to effectively present a user interface which will scale properly over the hundreds of different android devices, all with different screen resolutions, aspect ratios, and device sizes.

The system testing was burdened by the fact that calls from Android were producing a Timeout Error on every attempt. With the help of Dr. Wurst, I am in a better position to get these calls working by the first week of the upcoming sprint.

I was impressed with this sprint, because our team accomplished the 2 main goals of this classroom effort, the first being to improve the skill-set of the team members in a “real world” development effort, and secondly, to help with the general progress of the LibreFoodPantry work to produce a product to help those less fortunate than ourselves.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

As a developer, I have always thought that “being a small fish in a big pond” rather than “a big fish in a small pond” was a great advantage for career advancement, both as a way to advance your knowledge, skills, salary, and position. I learned an incredible amount from other developers at EMC, Nuance, and Kodak, because these companies had teams where many of the engineers were brilliant and knowledgeable yet had no problem meeting with me to share information, and help with difficult design and debugging challenges. Although I usually obtained more from these teammates that I taught them, enough situations came up when I was helpful to them that they were happy to help me when I needed them.

I usually took the approach of only “bothering” them when I was really stuck on an issue. This had the benefit of making me fully understand the problem, and therefore taking less of their time. Before I would ask for a meeting on such an issue, I would take notes on what the problem was, and then write down a list of questions to ask. I found that some of the time, when I did this, I was able to get the answer on my own. Another interesting phenomenon would occur quite often. I would actually be able to come up with the answer to the problem on my own as I was going through the issue with them. I would then get a response like “See Joe, you already knew the answer. You just didn’t know you did”.

The whole concept of “sink or swim” is quite interesting. When working in a challenging environment, I was always more motivated to learn the skills necessary to produce solid code than when I was one of the more advanced team members. Since most of my career was as a consultant/contractor, sinking at a company was less problematic than when I was working as a corporate employee. The expectations of working as a consultant were usually higher. You were treated less as a team member by some also.

I found, though that I really liked both worlds. About a third of my career, I worked as an employee, and enjoyed the benefits of “being part of the team”, getting paid vacations, going to conferences for free, and the obvious sense of security. The other two thirds of my years in software either contracting as a 1099 or W2, or when I hung my own shield with my corporation “Twinstar Enterprises Inc”.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

This pattern explains the benefits of reading real world source code. If you are on an assignment and are asked to write a small component for the project, your most important task should be to read through the code-base and understand as much of the source code as possible, given the time constraints you are under. It is important for you to understand the intent of the application at a high level before studying the code, but then to immerse yourself in how the code works, how it is structured, what design patterns are used, how the class hierarchy work, and which developers were involved in the project. In most cases, it would be a mistake to try to learn all the project’s code, unless it were quite small. Consider understanding the code involved most closely to your intended assignment with the most priority. Most projects you will encounter are medium to large scale applications, and some would take you months to adequately understand.

Try meeting with the developer who wrote code most similar to what you are being assigned , and ask for tips and tricks on methods they used to build their pieces.

If you are asked to write, for example, an android activity that calls REST API’s, look for related YouTube videos, Google documentation, related code on GitLab or GitHub, textbooks, stackoverflow.com posts, and college library references, but most importantly, look directly at the code-base you are working with to find if similar code has been written which can be cloned, modified, and sometimes improved. I have worked on projects where the same basic code had been written more than once! Refactoring an application to remove repeated code, or to consolidated similar code is a huge time saver. There is nothing like management giving you a month to write something, and you come back in two days with it done. This is the type of “magic” you can accomplish if you are observant of the resources that already exist in your project, and the Open-Source world in general.

I also think it is important to read through code you have previously written. If you have resume entries stating you know a particular language or technology, a more than rudimentary understanding of it is really important for your next review or interview. As your career develops, the list of these items will increase, and some will become somewhat obsolete, so it is much more important to understand the most recent skills best. If you can’t recite a paragraph or two on any given entry, I would consider removing it from your resume.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

This pattern describes the benefits of maintaining a reading list of books on Computer Science. It suggests that you list of “Long Lived books” you have already read, as well as listing books you plan to read in the future. It reminds me of a number of books I have read that are essential reading for any developer. I have read “Code Complete”, “Writing Solid Code”, “The C Programming Language” by Kernigan and Richie, and a few others that are truly “Long Lived Books”. It is interesting that these books have stood the test of time in such a strong way, considering the accelerated progression of technologies. Most technical books and periodicals do not fall into this category. An example of this from my own experience is the plethora of books that appeared on the market when OLE, COM, and ATL became popular in the late 90’s. I bought at least 6 of these books, and they became obsolete rather quickly. As soon as a new release of these technologies occurred, a number of relatively poorly written books were pushed onto the market, having been written by authors who were more concerned with “time to market” than quality of information. Ultimately a “Best in Breed” book would appear, but this usually came out months after the release.

Your list should also contain books that you plan to read, sorted in order of importance to what you need to know currently, as well as those that you have discovered fit the category of long-lived books. Strongly favor the ones that have been recommended to you by mentors or peers but do your own research to find others. I have been helped over the years by periodicals. The better of them tended to have the better quality of writing at times of product release than most of the books being pushed at us. Some of my favorites are (were) MSDN Magazine, Microsoft Systems Journal, BYTE, Wired, PC magazine, and Computerworld. Keeping up with the mags was more helpful to my career than any of the books, with the exception of a dozen or so of them.

I kept a list of the books and magazines I had read I thought were important on my CV. This way, I was able to update my reading list whenever I was updating my resume. This kept the list fresh and up to date.

Now that we are exposed to audio books, blogs, podcasts, and YouTube videos, I tend to get most of my knowledge from them than from traditional books and periodicals, but the basic concepts of this pattern stand firm.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

The Breakable Toys describes how to set up a situation where you can continue to learn and make progress with your career without unduly affecting your performance as a developer on your “day job”. The idea is to create a home-based work environment where you can develop product to enhance your skill set by making small products on your own. If these fail, or turn out to be flawed in some way, there is no downside, because you are expected to have learned lessons on your own. Although most work-paces are reasonable when your coding doesn’t come out perfect the first time, it certainly is much better for your career if you develop working, useful, optimal code in a reasonable time frame.

Many developers don’t have the time or inclination to do this, and turn out to be productive employees, but those who guide their own career by making their own products on the side are much more likely to succeed both intellectually and financially.

Throughout my career, I have always been motivated to keep up with the current journals, attend classes and conferences, and to always have a product I was developing on my own. In the 1990’s I developed a music-based utility program for guitarists called “Guitar Companion”. It’s most impressive component was a notation editor, but it also had a metronome, tuning fork, band manager component, and 3 CD’s with Video Guitar Lessons. I wrote it in Visual C++. But over the years, converted it to new technologies, and sold it through a website I had constructed fo4r this purpose.

From 2010 to 2015, I developed a number of Android applications for musicians. The one that turned out the best I sold on Google Play and had over 20,000 downloads.

This was all great for my career growth, but I would have never done this if I were not passionate enough to put in the time and effort. I highly recommend this approach to anyone who really loves to code. You are your own CEO. You call all the shots. You become sought after by companies, because you have developed depth in your code base that few can attain working under the strict protocol of working for someone else.

It also works in reverse. I would incorporate functionality into my “Toy” products that I learned at job-sites, as well as using things I wrote at home into my work products. It is pretty great when a boss asks during a scrum “who knows how to do X”, and you raise your hand. “ I do”.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.