As IT engineers we know that the rapidly changing technology landscape is difficult to maintain. We continue to shuffle from the speed of change, constantly learning new tools, techniques, languages and structures. The application technologies are soon supplanted or invalidating the technologies we already know. We constantly compare one technology rather than another, deciding what to learn later, and it is easy to get lost in a sea of competing possibilities. Staying able to live in a software development career means keeping up with this. The constantly evolving expectations of applications imply the constant demand to add X or Y functionality even if the functionality does not necessarily make sense for the application.
Lots of material is out there – books, videos, in-person or online training courses, websites, blog postings tutorials and more. It is easy to spend all the time in training without ever having started a project.
Writing on FreeCodeCamp, Tony Mastrorio wrote about how he was afraid of starting a "side project" because of how much he did not know how to do. Instead he would buy course after class, hoping the next tutorial would teach him everything he needed to learn. He could think of a project, but he has no idea how to implement some aspects of the project. Then he would let himself be involved in learning that piece only to lose track of the project. That is, until it started on a different path.
What happens if making progress in a project means focusing on training enough to learn the slice of technology required for a specific task? There is a certain basis of programming knowledge that we all need to have to be competent programmers. Beyond this base, do we need to know every square inch of React or Vue.js or anything else to develop an app?
A few months ago I started studying Vue.js. I started with a Udemy course and I only saw a little bit of the course to get some concepts, so I was launched in the programming. When, or if, I need to learn more, return to the course or other information to learn what I need. I will describe the current project, using Vue.js in Electron to create a & r; desktop app, in a bit.
You can start a project without knowing all the technology and working on it as you go. It is about managing one's time and focusing on priorities, learning only what is needed to fill in the knowledge gaps needed to complete the project.
My experience during the learning of Node.js is an example.
My contract with Yahoo ended before the launch of the Mojito / Manhattan project, so I do not know how it ended. Writing the book was immensely fun, but getting to that point meant facing many challenges.
I could write – I've been blogging for about 10 years at that point, and I was writing news articles for about a year. But blog posts and news are tiny compared to a book. Writing a book, an entire book, alone, seemed enormous.
A fundamental thing I learned is: instead of being overwhelmed by the totality of a book, develop a good structure. So writing the book becomes a series of essays. Writing a theme, or tutorial tutorials or blog posts, is easy. Writing a book is simply writing a series of such essays. Everyone must adapt to what is in the outline and everyone must flow into the next. All you need is resistance and attention to follow until the end. The signing of a contract to be executed has a way of giving resistance and concentration.
Once me had that point of view, writing the book became easy and fun.
Obviously many are frozen or otherwise scared to do something, and the model is obviously not limited to software development projects. We will be stuck inaction and we can not make progress for any reason. We may have the destiny to move into a new position, to embark on a new career or to present a new taste of ice cream to try. How many people do not know how to buy a house, think that buying a house is too complicated or that the real estate sector is full of scammers and will never buy one. Being reluctant or being afraid to try something new, whatever the scale, can mean losing the opportunity.
Several times I have just launched myself into completely new things. For example, the desire to contribute to the acceptance of electric vehicles led to work as a journalist writing news articles. I did not know journalism, but I did it anyway and I learned by doing, writing at the end a couple of thousands of articles. People tell me I have a talent, and the role of Truth Teller is a lot of fun. Let's talk about some general principles before describing the project I am currently developing.
- Specific objective: It is better to keep in mind a project or a goal. You should be able to clearly describe the goal.
- Break it into pieces: Keep it at a fairly high level at first, and while brainstorming use the goal statement to decide which pieces belong or do not belong to the project.
- Divide the pieces from what you do or do not know how to do.
- List the pieces, information, data and other support can be useful, in a workbook or in a planning book. Continue to update this resource as you go. Trello or similar apps are very useful.
- Use Agile project management techniques: The freedom to adjust the project as you go is powerful
- Look for positive intentionality: You can achieve the goal, even if it seems a bold and impossible goal
- Do not fool yourself because a goal could actually be impossible.
- Be realistic in the evaluation of the project, without entering self-destructive schemes. Many of us have strong doubts about ourselves that actively prevent us from doing things.
Keeping the positive intention firmly is powerful. Engaging deeply in the possibility that the goal is achievable is powerful, as is cultivating the mentality of always looking for the way to successfully reach the goal. Positive intentionality can guide you through the minefield of self-doubts and other oppositions that often emerge.
Some projects go beyond the realm of human possibilities. It does not help if your positive mindset is self-delusion. Likewise, it does not help if what you think is a realistic assessment is guided by self-destructive self-limiting belief structures.
I believe everyone should take bold impossible goals. Mine is putting an end to the use of fossil fuels. I do not know how to achieve this, but it is clear that if human society has to survive, we must do it. In pursuit of this goal, I do a series of actions such as running online forums on electric vehicles, writing thousands of articles, answering questions about Quora, learning to design solar panels and writing a book about best practices for charging of electric vehicles. Even just declare the goal here brings us closer to a few micrometers.
I started a software project that is a great example of setting positive goals and tackling seemingly impossible challenges.
It will be a 'desktop app to help users create e-books formatted with EPUB3. It will take a directory of files that could be in multiple formats (HTML, Markdown, AsciiDoc, RTF, ODT, etc.), Render them in XHTML specific to EPUB3 and group them with the correct metadata files as specified in EPUB3.0.1 standard. It will be made with Electron and will be sold via Mac and Microsoft App Store. The user interface will be created using Vue.js, using the Buefy component library, and will work to be easy to use while offering a complete configuration of the details of EPUB 3.0.1.
This is a bold goal and there are several tasks in the project that I do not know how to do. For example, while you can sell an Electron app through app stores, I have no clue how to do it, and this is not the only seemingly impossible task in the backlog.
Every goal is declared in a positive frame, even for the goals in which I have no idea what to do.
Every goal is stated knowing that it is theoretically possible. I know that all these steps have been done by others, so obviously I can do the same. There is no trembling "I do not know how" that would hold me back. When the project reaches each of these strangers, I will solve it.
I have a Trello card to keep track of the remaining activities. I'm constantly reevaluating the plan as I work on the project and I'm not afraid to fix things as I learn how the application will work.
I do not have to be an expert on the whole technology stack. The project itself focuses on learning the specific pieces of the stack needed for the project.
One thing I 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. In 3 days of research I learned that in fact an EPUB3 document includes XHTML files, uses modern HTML5 and CSS elements and that ZIP is the packaging format. I had also developed a prototype tool in Node.js to build 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 is reduced to a configuration GUI for a semi-complex XML file containing metadata. The OPF file (Open Package Format) contains several data elements such as dc: identifier or dc: title tags that can be treated as a table. A book could have multiple identifiers for different purposes, such as an ISBN for some audiences and a DOI for other audiences. Or it could have a common title, a long title, a short title, different titles for different languages and so on.
Of course, the application requires a method for the user to add or modify or delete items in multiple tables. But how?
First I tried to avoid. I wrote all kinds of code in addition to the tables. Why today what can you postpone to tomorrow?
Yes, I did it and I knew I was doing it. How many postpone the inevitable? In the end I finished the other tasks and I had to face the implementation of the tables.
What are you doing? You have painted yourself in a corner and the only way out is to do the thing you have postponed. But you have no idea what to do. Is not it a recipe to stay frozen in fear? Or maybe some other destructive tendency, like surrendering. How many projects do we start, just to get stuck in a task you do not know how to do, just to put aside the project where it collects dust in the back of the garage? (That was an electric motorcycle that I tried to build just to get bigger by building a custom frame, and then to cut it into small pieces a couple of years and dump it in a trash can.)
For the Vue.js coders a potential resource for the "I do not know how" questions is the awesome-vue repository. It is a complete list of Vue.js tools and components. There is a component section of the Vue.js table and I started looking at the list and evaluating each to see if it is possible to use one. There are several noteworthy table components, but then it came to mind that Buefy (the Vue.js toolkit in use) could have a table component. Actually it does, but the documentation leaves a lot to be desired. It took a couple of days to figure out what to do.
This is what came to my mind:
Here are a couple of tables to handle the
dc: creator is
dc: collaborator lists. Each line has a couple of buttons to edit and delete that line. The button marked with the plus sign adds a new line and the table supports pagination if there are too many lines to display.
Maybe it's not the best user experience, but it's functional and has moved the project beyond an apparent inability. In the meantime, I can continue to complete the basic functionality.
Does this seem completely natural? I had built this impossible task in my mind which proved to be relatively easy. I had engaged in avoidance strategies, postponing the task of delaying the inevitable, and then it simply turned into a puzzle on how to implement the Vue.js / Buefy component that was right in front of me. How many of our life tasks are like that? Let's make it more difficult than it really is, spread it out of all proportion, and then it turns out to be easy. Obviously there are also those tasks that we consider trivial and that always require a result at the end, so everything is balanced.
With a bit of luck, the other tasks in this project will be just as anticlimatic. The bulk in my mind is the packaging for the app stores. There are applications based on Electron in the app stores, so of course it is possible, and the Electron documentation has a page that describes what to do.
The stranger can invoke fears Whatever unknown task brings us into a new territory where we do not know what to do, and fear grows easily. Even if it's just a matter of carefully reading the documentation and doing what it says it does, fear has a way to take over and upset logic.
Many spiritual practices teach you to observe your inner state. The first phase is noting "oh, this is causing me fear"And the next step is working with the problems that cause fear, some suggest"Feel the fear and do it anyway", Which can be a strong attitude to develop.
Great strength can be achieved by facing and walking through those that were self-limiting fears.
We started talking about the rapid change in the software industry. We are constantly trying to keep up with new things to avoid being left behind. We are constantly entering a new unknown territory, facing the problem of not knowing how to do X or Y using the new toolkit. Even if we already knew how to run X in another toolkit, it stayed behind … e.g. jQuery has been left behind the new frameworks … and we have to re-learn old skills using new tools.
Constantly directing to the unknown can be unnerving and, above all, trigger fears that would prevent us from achieving our goals. This model is not limited to writing software, but it can have repercussions everywhere in our lives. What matters is our ability to navigate through the unknown to arrive from the other side. In Solo: a stellar war story, we finally learned what Han Solo meant when he boasted the Millennium Falcon made the Kessel Run in 12 parsecs. Not to ruin the story, but it was about flying in unknown lands and finding a road that no one else had ever found before.
This is the essence of the Hero's Journey history format. We start towards a goal, we find a difficult point where everything seems impossible, but make your way fighting, we hope to reach a positive conclusion. Crossing that difficult point gives us not only a piece of working code, but an inner gift of trust and greater experience.