As software engineers we know the quickly changing technology landscape is hard to keep up with. We’re kept scrambling by the speed of change, constantly learning new tools, techniques, languages, and frameworks. Application technologies are quickly supplanted or invalidating the technologies we already know. We’re constantly comparing one technology over another, deciding what to learn next, and it’s easy to get lost in a sea of competing possibilities. To stay viable in a software development career means keeping up with this. The constantly evolving expectations of applications means a constant demand to add feature X or Y even if the feature doesn’t necessarily make sense for the application.

Lots of material is out there — books, videos, training courses in person or online, websites, tutorial blog posts, and more. It’s easy to spend all your time in training without ever getting started on a project.

Writing on FreeCodeCamp, Tony Mastrorio wrote about how he was afraid to start a “side project” because of how much he didn’t know how to do. Instead he would buy course after course, hoping the next tutorial would teach him all he needed to learn. He might think of a project, but have no idea how to implement some aspect of the project. Then he’d get caught up in learning that piece only to lose track of the project. That is, until he started on a different path.

Over on Quora I recently answered a question about how long would it take to learn JavaScript completely and start developing programs. I answered that you simply don’t need to learn JavaScript completely to start using it. Most of us start with little snippets of JavaScript on web pages and it’s possible to do quite a lot to improve a web page with a few lines of code. Even with Node.js programming it’s possible to do quite a lot with a small bit of code. JavaScript is a very expressive language, and the breadth of modules available in the Node.js ecosystem means almost every need can be satisfied through using an existing module.

The JavaScript ecosystem is large and you can accomplish powerful things with JavaScript — case in point is that I’m writing this in Google Docs, an in-browser word processing application. Knowing JavaScript in depth is a great idea, but is not a requirement.

What if making headway in a project means focusing on just enough training to learn the slice of technology required for a specific task? There is a certain base of programming knowledge we all must have to be competent programmers. Beyond that base, do we need to know every square inch of React or Vue.js or whatever to develop an app?

A few months ago I started learning Vue.js. I started with a Udemy course and watched just enough of the course to get some concepts, then launched into coding. When, or if, I need to learn more I return to the course or other information to learn what I need. I’ll describe the current project, using Vue.js in Electron to build a desktop app, in a little bit.

It’s possible to start a project without knowing the entirety of the technology, and to work it out as you go. It’s a matter of managing your time and focusing on priorities, learning just what is needed to fill in knowledge gaps required to finish the project.

My experience while learning Node.js is an example.

I was thrust into JavaScript programming in a big way. First, our team was reassigned to work on Yahoo’s Node.js application hosting platform known as Mojito/Manhattan. This was in late 2010, and Ryan Dahl had given presentations at Yahoo about Node.js earlier that year. Second, at around the same time I’d been contacted by Packt Publishing to be the Technical Reviewer on a book about Node.js programming. Cool, I thought, a way to learn Node.js while working with it in the job. Next thing I knew, Packt told me the author they’d lined up had backed out and asked if I was interested in writing the book. Nervously, not knowing how to write a book, I said “sure”.

There I was, knowing very little JavaScript suddenly “working with” a brand new platform for JavaScript programming. This wasn’t just for a small scale side project. It was two projects with large significance: What was to be a major tool for Yahoo, and what was to be one of the first books on Node.js programming on the market. The first edition of Node.js Web Development was published in August 2011, and the fourth edition was published in June 2018.

I could have gotten scared and frozen into inaction by uncertainty. Did I know JavaScript? No, not sufficiently for either of those tasks. Nor did I know how to write a book. There were plenty of aspects to book authoring I simply did not know, which I learned by being thrown in the deep end. It would have been easy to freak out at the responsibility.

My contract at Yahoo ended before the Mojito/Manhattan project launched, so I don’t know how that turned out. Writing the book was immensely fun, but getting to that point meant facing many challenges.

I could write — I’d been blogging for about 10 years by that point, and had been writing news articles for a year or so. But blog posts and news articles are tiny compared to a book. Writing a book, a whole book, on my own, that looked enormous.

One key thing I learned is: Instead of getting overwhelmed by the entirety of a book, develop a good outline. Then writing the book becomes writing a series of essays. Writing an essay, or how-to tutorial, or blog post, is easy. Writing a book is simply writing a series of such essays. Each must fit what’s in the outline, and each must flow into the next. All that’s required is the stamina and focus to follow through to the end. Signing a contract to perform has a way of giving one stamina and focus.

Once I got that point of view, writing the book became easy and fun.

Obviously many get frozen or otherwise scared to do something, and the pattern is obviously not limited to software development projects. We’ll be stuck in inaction and cannot make progress for whatever reason. We might have a destiny to move to a new location, take on a new career, or be presented with a new ice cream flavor to try. How many people don’t know how to buy a house, think buying a house is too complicated, or that the real estate industry is full of crooks, and will never buy one. Being reluctant or afraid to try something new, whatever the scale, can mean we miss out on opportunity.

Several times now I’ve just launched myself into completely new things. For example, a desire to contribute to the acceptance of electric vehicles led to working as a journalist writing news articles. I didn’t know journalism, but I did it anyway and learned by doing, eventually writing a couple thousand news articles. People tell me I have a talent, and the Truth Teller role is very enjoyable. Let’s talk about some general principles before I describe the project I’m currently developing.

• Specific goal: It’s best to have a project or goal in mind to give focus. You should be able to clearly describe the goal.
• Break it down into chunks: Keep it at a fairly high level at first, and while brainstorming use the goal statement to decide what chunks belong or do not belong in the project.
• Divide the chunks by what you do or don’t know how to do.
• List the chunks, supporting information, data, and anything else that may be useful, in a workbook or planning book. Keep updating this resource as you go. Trello or similar apps is very useful.
• Use agile project management techniques: The freedom to adjust the project as you go is powerful
• Seek positive intentionality: It is possible to achieve the goal, even if it seems like an audacious impossible goal
• Do not delude yourself since a goal may actually be impossible.
• Be realistic in evaluating the project, without getting into self-destructive patterns. Many of us have strong self-doubts that actively stop us from achieving things.

Firmly holding positive intention is powerful. Grounding yourself in the possibility the goal is achievable is powerful, as is cultivating the mindset of always looking for the path of successfully reaching the goal. Positive intentionality can guide you through the minefield of self doubts and other opposition that often crop up.

Some projects are beyond the realm of human possibility. It doesn’t help if your positive mindset is self-delusion. Likewise it doesn’t help if what you think is a realistic assessment is driven self-destructive-self-limiting belief structures.

I believe everyone should take on audacious impossible goals. Mine is ending the use of fossil fuels. I don’t know how to get to that goal, but it’s clear if human society is to survive we must do so. In pursuit of that goal, I do a number of actions like running online forums about electric vehicles, writing those couple thousand news articles, answering questions on Quora, learning how to design solar arrays, and writing a book about best practices for electric vehicle charging. Even just stating the goal here gets us a few micrometers closer.

I’ve started on a software project that is a great example of setting positive goals, and working through seemingly impossible challenges.

It will be a desktop app to help folks build EPUB3-formatted e-Books. It will take a directory of files that could be in multiple formats (HTML, Markdown, AsciiDoc, RTF, ODT, etc), render them to EPUB3-specific XHTML, and bundle them with the correct metadata files as specified in the EPUB3.0.1 standard. It will be built with Electron, and will be sold through the Mac and Microsoft app stores. The UI will be built using Vue.js, using the Buefy collection of Components, and it will strive to be easy-to-use while offering comprehensive configuration of EPUB 3.0.1 details.

That’s an audacious goal, and there are several tasks in the project I don’t know how to do. For example, while it is possible to sell an Electron app through the app stores, I haven’t the foggiest idea how to do so, and that’s not the only seemingly impossible task in the backlog.

Every goal is stated in a positive frame, even for the goals where I have no clue what to do.

Each goal is stated knowing it is theoretically possible. I know all those steps have been accomplished by others, so of course I can do the same. There’s no quivering “I don’t know how” which would hold me back. When the project gets to each of those unknowns, I’ll work it out.

I have a Trello board to track the remaining tasks. I am constantly reevaluating the plan as I work on the project, and am not afraid to adjust things as I learn how the application will work.

I don’t have to be an expert on the whole technology stack. The project itself focuses me on learning specific pieces of the stack required for the project.

One thing I do know is the EPUB3 specification. About 4 years ago I woke up one morning with a vague memory that an EPUB is just a ZIP archive of HTML-ish files. Within 3 days of research I’d learned that indeed an EPUB3 document is comprised of XHTML files, it uses HTML5 elements and modern CSS, and that ZIP is the packaging format. Further I’d developed a prototype tool in Node.js to construct EPUB documents. A more refined implementation of that tool is the core of this application.

A recent challenge in the project is instructive. The application boils down to a configuration GUI for a semi-complex XML file containing metadata. The OPF file (Open Package Format) contains several data items like the dc:identifier or dc:title tags which can be treated as a table. A book might have multiple identifiers for different purposes, like an ISBN for some audiences and a DOI for other audiences. Or it might have the common title, a long title, a short title, different titles for different languages, and so on.

Clearly the application needs a method for the user to add or edit or delete items in multiple tables. But, how?

First I tried avoidance. I wrote all kinds of code other than the tables. Why do today what you can put off until tomorrow?

Yes I really did that, and knew I was doing it. How many put off the inevitable? Eventually I ran out of other tasks and had to face implementing the tables.

What do you do? You’ve painted yourself into a corner, and the only way out is to do the thing you’ve been putting off. But you haven’t a clue what to do. Isn’t that a recipe for getting frozen in fear? Or maybe some other destructive tendency, like giving up. How many projects do we start, only to get stuck with a task you don’t know how to do, only to set the project aside where it gathers dust in the back of the garage? (That was an electric motorcycle I tried to build only to get majorly stuck fabricating a custom frame, and then to cut it into tiny pieces a couple years and dump it in a trash bin.)

For Vue.js coders a potential resource for “I don’t know how” questions is the awesome-vue repository. It is an extensive curated list of Vue.js tools and components. There is a section of Vue.js table components, and I started down the list evaluating each to see if one could be used. There are several worthy-looking table components, but then a thought came that Buefy (the Vue.js toolkit being used) might have a table component. Indeed it does, but the documentation leaves a lot to be desired. It took a couple days to work out what to do.

This is what I came up with:

Here’s a pair of tables to handle the dc:creator and dc:contributor lists. Each row has a pair of buttons to edit and delete that row. The button marked with the Plus sign adds a new row, and the table supports pagination if there are too many rows to display.

Maybe it’s not the best user experience, but it’s functional and moved the project past a seeming impossibility. In the meantime I can get on with finishing up the basic functionality.

Does this seem anticlimactic? I’d built up in my mind this impossible task that turned out relatively easy. I’d engaged in avoidance strategies, putting off the task to delay the inevitable, and then it simply turned into puzzling out how to implement the Vue.js/Buefy component which was right in front of me. How many of our life tasks are just like that? We make the thing out to be more difficult than it really is, blow it out of proportion, and then it turns out to be easy. Of course there’s also those tasks we think are trivial which end up taking forever to accomplish, so it all balances out.

With luck the other tasks in this project will be just as anticlimactic as they come up. The big one in my mind is packaging for the app stores. There are Electron-based applications in the app stores, so of course it’s possible, and the Electron documentation has a page describing what to do.

The unknown can invoke fears. Any unknown task takes us into new territory where we don’t know what to do, and fear easily crops up. Even if it is just a matter of carefully reading the documentation and doing what it says to do, fear has a way of taking over and crowding out logic.

Many spiritual practices train you to observe your inner state. The first stage is noticing “oh, this is causing me fear” and the next stage is to work with the issues causing the fear. Some suggest to “feel the fear and do it anyway”, which can be a powerful attitude to develop.

Great strength can be gained by facing and walking through what had been self-constraining fears.

We started this talking about the rapid change in the software industry. We’re constantly scrambling to keep up with new things to avoid being left behind. We’re constantly entering new unknown territory, facing the issue of not knowing how to do X or Y using the a new toolkit. Even if we already knew how to do X in another toolkit, it got left behind … e.g. jQuery has been left behind in preference for new frameworks … and we have to relearn old skills using new tools.

Constantly heading into the unknown can be nerve-wracking, and more importantly trigger fears that would prevent us from accomplishing our goals. This pattern isn’t limited to writing software, it can crop up anywhere in our life. What matters is our skill in navigating through the unknown to make it through to the other side. In Solo: A Star War Story, we finally learned what Han Solo meant when he bragged the Millennium Falcon made the Kessel Run in 12 parsecs. Not to spoil the story, but it involved flying into unknown territory, and finding a path nobody else had found before.

That’s the essence of the Hero’s Journey story format. We start towards a goal, find a tough spot where everything looks impossible, but fight our way through, hopefully reaching a successful conclusion. Making it through that tough spot gives us not only a working piece of code, but an inner gift of confidence and greater experience.