Cover photo taken in my work office at my university. Paper is Kara et al. 2016 (free at https://arxiv.org/abs/1501.06849).

I was recently involved in a brief Twitter thread with a fellow Dev.to blogger, Pachi (who you should totally check out ), and the topic of discussion was that there seems to be so much to learn. I mean, with a seemingly infinite number of tech blogs to read, YouTube tech education channels to watch, and Udemy courses to take, it can seem a bit overwhelming. This is especially true for someone new into this space, and is starting to realize just how much there is to learn. It can really make someone's head spin!

I've detailed my story in a previous blog post , and those who know me know that I'm coming into the tech field from quite the unique angle. My experience as an Astrophysicist and a PhD student has been kind of "trial by fire" for productivity and self-learning, and I hope that I can help some of you by imparting my views on the subject.

Before I begin, I will say that, in no way am I claiming that my ideas are wholly original. I've picked things up piecemeal from colleagues, self-help literature, and online sources. I am only speaking about what I've done that has proven effective for myself, and in no way am I claiming that these tips will necessarily work for everyone. I do believe that I can help at least a few people by sharing my opinion.

Note that I purposely have been vague as to when I'm talking about learning or general productivity, because in my opinion, everything can be described in terms of project management. Learning is a particular use case for what I'm about to describe where you are the project.

So, Where Do I Start?

I think one of the hardest parts of any project is figuring out where to start. After all, unless one is following some tutorial or has some outside guidance, it is often the case that they won't know where to even begin to learn about a particular subject or start a project. It's somewhat akin to the pressure one feels as they initially sit down to write and they are met with a blank, white page with a blinking cursor. We might have a vague idea in mind (e.g. "learn web development", "build an application", etc), but beyond those vague borders, we are left without a guide.

This uneasiness in almost complete freedom can lead to shut down, as the task seems just to great to even begin, or it can lead to going all directions simultaneously. Neither of these common results lead to particularly good results, as neither result in great productivity. For example, I remember when I was first started researching all the various programming languages, I thought it would be great to learn as many as I possibly could, and that would make me a great programmer. Don't get me wrong, I'm still very impressed by truly great polyglot programmers. However, you need to be able to do more than print "Hello, World!" in 20 different programming languages.

We cannot run from it. We must firmly answer the question: where do we begin?

The Recursive Productivity Function

Well, we must first actually do a bit of basic research on the domain we are trying to understand. For this, we have to ask:

1. What exactly do I want to do? What is my primary goal?
2. What does that exactly entail?
3. In my own words, can I break this down into individual steps?

Let's use the example of someone wanting to build a simple to-do list web app. Going through these three questions:

1. I want to build a to-do list web app.
2. I need to build a UI where a user can add entry to a list and then delete them after they are done. I also want to make sure the list saves.
3. Breaking down this process, I have: Build a basic skeleton of a web page, style said web document, make this web page dynamic to allow for adding and deleting entries, allow this web page to save the entries for later (even after shutdown)

Now then, based on the answer to #3, we have some more concrete steps. Obviously, this is a bit of a simplified example, but what's wonderful about this list of questions is that it can be used recursively. Each individual step that you list in question #3 could then be inserted back into this productivity function , which will produce its own list of steps. The final list of steps to be completed would then be produced by concatenating the results from each of these individual analyses.

The level to which you wish to push this is ultimately up to you and your skill level, but in my opinion it is best to have broken your original goal down to the point that the first step (or next step) seems almost trivial. By doing this, you've effectively constructed a framework to work in where there wasn't one before. You've traded in the pressure of an large-scale problem to that of making many small steps that can be overcome. It now isn't just one big goal, one big win, but many small goals, and many wins. I can guarantee that this will make you less nervous, make the process more fun, and help you fend off imposter syndrome.

Learning From Your Goals

Going back to the example of a newbie web app developer, they now know that they need to construct the basic structure of a UI. It doesn't have to look pretty, but it has to at least have the basic form. If they already know HTML or know some Web Framework (e.g. React, Angular) this may mean that they can get into this process immediately, but if they don't, then with an extra iteration of our productivity function , they know that their first step is to learn HTML.

Eventually, from a single idea (a simple to-do list application), our hypothetical newbie web app developer could eventually learn from the individual steps listed above:

1. Skeleton UI - HTML
2. Styling of UI - CSS
3. Making the webpage dynamic - JS
4. Saving the listed items - NodeJS, Express, SQL (or some other database query language, e.g. MongoDB)

By keeping their goals in mind, they have not only built the app that they had in mind, but they've also learned quite a few fundamental skills along the way.

Could they have taken a different approach, with a different tech stack? Absolutely. They are still learning the fundamentals of the development process, however, which is ultimately the most beneficial thing.

This brings us to another important point...

But What If It's Not Perfect?

I must admit, I can be a bit of a perfectionist at times, and while this has been beneficial in many ways, it can also have many detrimental side effects. One of the most relevant to this discussion, is that, very much like the pressure from a lack of concrete direction, a pressure towards perfectionism can also result in the grinding of true productivity to a halt.

If a code is never shipped, does it truly matter if its becoming increasingly more perfect?

This point is relevant to the discussion, because people will often anguish over a particular point of deciding the method by which they will reach one of their particular goals in a project. This is often times the result of, once again, too many options.

Don't Anguish Over Finding A Perfect Tech Stack

Taking the example of the web app, when determining how our hypothetical developer is going to design their to-do list program, they are likely to encounter people talking about a plethora of front-end frameworks. Should they learn Python and pick up Django or Flask? Perhaps JavaScript and use React, or maybe learn this hot new TypeScript and use Angular? What about Ruby and Rails? Of course, each framework rely on different languages and use different paradigms (client side vs. server side rendering), so perhaps you should learn all of them and then pick the perfect one. Ad infinitum...

I hope this example shows you that you should try your best to not labor over such things, especially when you are starting out. There will be time and a place to learn different frameworks for different projects. For any particular project, however, I think it is important that you try to police your thoughts before they snowball out of control. In over to overcome such issues and the anxiety that come with them.

The Minimum Viable Product

I think we can borrow a term from the software industry, and focus at first on the minimum viable product (MVP) . There is always time to make a project better after it is initially shared with the world.

For our hypothetical complete newbie web developer with the to-do list app, it is not the case that he needs any fancy framework. They could produce the front-end of an initial version of their product (their MVP) with base HTML, CSS, and JavaScript. This allows them to learn the fundamentals first, and then either come back later to refactor the project using such popular framework or start another project where they use such a framework (thus giving them an excuse to learn it as a step in the development process).

Be Content With Imperfection With Constant Improvement

I would like to also point out that the principle that you shouldn't get bogged down by the strive for perfection can also pertain to the self as well. For example, I remember many times during my early years of coding that I felt like I couldn't forget anything, and that everything I did needed be perfect. If I didn't remember something, clearly I needed to go over yet another tutorial or re-read a chapter in a book that I had just read a few weeks before. This urge to hold myself to such a unrealistic standard resulted being unproductive, increased my anxiety, and reinforced my imposter syndrome.

The pursuit of absolute perfection, either in the building of a project or in the development of the self, is a foolhardy venture. It is important that we always try to better ourselves, to learn and grow, but we must consciously realize that we will never reach some ultimate self or produce some ultimate project. We must be willing to forgive imperfections, and get fulfillment in the constant journey of improvement .

Don't overthink the process. Focus on your goals. Forgive imperfections. Finally...

Focus On Fundamentals First

One final thing I want to cover is the importance of fundamentals. What I mean by, "fundamentals," is those most components of your tech stack. In the case of our hypothetical newbie web developer, this would be HTML, CSS, and JavaScript. In the case of a data scientist, it would be Python, SQL, and basic statistics. They also include fundamental coding concepts, like the idea of a loop, a variable, an array, an object, etc.

This is analogous to the MVP concept, where you should produce the smallest, most basic, useable component first. In this case, you are the project, and those learning those basic fundamentals would be considered producing your MVP. Do those fundamentals necessarily make you job ready, or do they necessarily complete your first big project? No, but they are undoubtedly going to provide the foundation on which you continue to build upon.

These basic concepts also provide a language so that you can more readily think about the task at hand, or any future project. This makes our recursive productivity function that I introduced earlier an easier process. Our fundamentals are provide a conceptual language with which we can start to understand the vague ideas that exist at the beginning of the development process.

Conclusion

I realize that this blog post may seem a bit simplistic, or perhaps even a bit vague. In a way, that is intentional, as I think the best method by which one goes about learning and producing will be incredibly dependent on the personality of the individual in question and the problem at hand.

That being said, I do believe that the main takeaways from this post can be applied almost universally as a kind of basic problem solving toolbox:

1. Use a recursive productivity function to break down larger problems or goals into smaller ones. Continue until the step your first (or next) step you are to take seems almost trivial.
2. Stay focused on the minimum viable product as a first attempt, being weary of the tendency for perfectionism. Always work towards improvement, but realize that perfection is never truly obtainable.
3. Focus on the fundamentals first . Learn the basic language and concept with which you will be working. Build on that foundation, but always keep those fundamentals in view, allowing you to steel yourself against mind clutter and keep yourself grounded. They provide a basic vocabulary and grammar with which you can start to parse vague goals, improving our efficiency as problem solvers.

With that, I will end this post, and I hope this has been helpful. Depending on interest, I may write more on this subject and turn this topic into a short series.

Take care, and happy coding!