Hi, my name is Jeff, and this is my website. I’ve written essays and half-essays over the years, and I recently refreshed by website with a focus on simplicity. I had this ambitious goal of writing the ultimate book on software engineering called the “Way of Code” which would manifest a playbook for anyone to go from plucky kid to rough and ragged principal engineer. Alas, my attempts to finish this book have been in vain as my own understanding is constantly evolving. Instead, I want to illustrate the fixed points which I believe were true yesterday and will be true into the future.
I intend to cut straight to the point since I can easily got lost as I’m retired these days focusing on my own passion project, Adama. One of the reasons I wrote a bunch was to cache my thinking as I mentored people throughout my career. I’ve helped grow many engineers of all levels, and when I reflect on my career this has been the most meaningful aspect. Helping people is just what we do, so hopefully these nuggets of wisdom are useful to you.
These were put down in no order, were written at different stages within my own career, and are here simply as a cache. If you enjoy them then please send me an email email@example.com and let me know.
At the end of the day, software is needed to help people. Whether to delight or organize, people use software achieve something in their life. Mastery of your craft and developing success in this field requires showing up, getting things done, shouldering burden of responsibility, and shipping software to people.
Please make sure you love a subset of the people you ship software for. If you don’t, then it’s only going to be harder.
Making software for yourself is fun, but making software for others is where you start to build your empire of awesomeness. The most important thing, for you, as a software person is to find the customers that you want to make awesome. You want customers that you can connect with and understand, so that you can deliver your best day in and day out. You want customers that will make you feel guilty for shipping crap.
You want customers that you are willing to suffer for.
Having any form of apathy for your customers, disconnectedness from your customers, or having a poorly defined sense of customer is a terrible way to live. Make sure that you can connect your work to actual people and how it benefits their lives, then your work will have both meaning and purpose.
Being smart is the application of creativity, developing feedback cycles, and working hard. This is the sound bite answer which drives further questions like: how does one be creative? how does one developer feedback cycles? what exactly does it mean to work hard?
These are good questions to ponder on any endeavor.
An important aspect of growth is to collect questions, and then use them regularly.
I’m a huge fan of side projects. Side projects are a great way to expand your knowledge of your craft and get a ton of practice in building software. My advice is to always pick something a bit crazy, and go try it. Just try something crazy, and it will be a rewarding adventure.
However, a natural criticism of side projects is that they are a signal that your day to day work isn’t satisfying. I don’t believe this is absolutely true; I find a great deal of interdisciplinary ideas and successes between both my side projects and my day to day. The problem is more of a social one rather than a technical or life satisfaction issue. The social signal of side projects is hard to ignore, and you need to be smart about it and gauge whether or not it could be a career limiting move. Simply put, do side projects for yourself until you are comfortable sharing (or change jobs when the time is right).
The natural resistance to side projects is “life”; you do have a “life” to live, so staying indoors glued to a project may not be the best life advice. The important thing is to learn balance, and that will be a struggle. I believe that investing early in your career will pay dividends, so it is worth it. However, the thing to keep in mind (which is in many ways excetionally unfortunate) is that you are competing with people that have side projects.
One day, your side project may be your main day to day project. This is the ultimate goal, and the most important part of doing side projects is to find the one true project and to get enough experience to be able to either (a) start a company or (b) join the market leader doing it.
Tell people what you are doing, but also listen and provide feedback on what they are doing. Ask questions! A good question will signal that you listened. A great question will probe for deeper understanding.
At core, communication is the fundamental most difficult aspect of building software. Be generous both with yourself and others, and find the patience to connect. Dive deep with people that you care about.
Once communication has been achieved, then sharing of knowledge can begin.
Just wake up, find the gratitude for breathing, and then work towards being a kind person.
We are tribal in nature and have fast thinking impulses. When you meet people, take a deep breathe and focus on seeing the underlying nature of the person in front of you.
Give people plenty of chances.
The base nature of being human is primal, raw, and nasty. Life is harsh and metal. People can be glib and mean. Text is a poor signal of nature as we communicate.
While you must try to be kind and work through our primal nature to unleash, others may not be as disciplined. It’s best to develop the patience to allow people the ability to speak their mind, hold back the immediate reaction, and then seek to calm everything down or tune appropriate feedback.
The technical community is particularly unique in that competence can be gained early while alone, and this can create a toxic community due a lacking in humility and full of isolation. Things get better when people put aside their primal ways and have empathy towards others.
Whatever you do, you become. If you constantly buy things, then you will master integration. If you constantly build things, then you master building. If you constantly invent things, then you will master invention.
Here is the deal, there is no wrong answer for your life. There are, however, wrong domains to enter. If you work for a marketing company, then you better learn to buy and integrate things together. If you want to work on the cloud, then you need to master the fundamentals of building on bare metal.
A key challenge is that the opportunities to build are fewer than to buy, and the opportunities to invent are fewer than to build. You can look at Price’s Law for the reasoning behind this where half of the work is done by the square-root of the people. This is a brutal reality to contend with, and this further illustrates the importance of side projects.
If you want to navigate from buying to building and from building to inventing, then you have to apply constant pressure to be one of the select few that do 50% of the work.
It’s important to note that there is no shame in just buying because there are a myriad of problems that need solving by building products for people.
However, you must come to terms with what you want out of your career and the effort and cost to achieve your aims. You can build successful businesses by simply focusing on solving people problems. You can achieve life-work balance. You can also invent like crazy. Each aspiration has a benefit and a cost.
Unfortunately, the cost may be unknown until it is too late.
Is it better to master MySQL or to try to invent your own database?
I’m a huge fan of inventing your own database simply because you will learn more by doing it. Sure you may realize at the end of it that it was a giant waste of time, or that the thing that you invented was kind of crappy, but you will learn many things that will apply to your next invention. Again, this is why I’m a huge fan of side projects. Your side projects are a great way to experiment and dabble in very risky things especially if you think they are interesting.
Now, you should be practical and not try to invent everything. You should focus and invent things that you think benefit your customers or enable you to deliver more for your customers faster with higher quality.
Creativity and inventiveness are like muscles that need exercise. The more problems you overcome by invention, the easier the next problems are. As a bonus, you will understand many of the design choices in the products that you use; this will inspire your designs to be simpler.
Suppose that you disagree with me and you should master MySQL, then what kind of skills do you build when you avoid NIH (Not Invented Here) syndrome religiously? Sure, you master what exists, but have you mastered the unknown? Will you have the skills to take a blank piece of paper and turn it into something amazing?
The more you do and learn, the more you will become aware of. The more you become aware of, the more things you will need to take into consideration. Consider the number of constraints possible when building software: cpu/time, memory footprint, power consumption, file counts, socket count, io capacity, network utilization, memory corruption, code size, number of threads, contention, other processes, files, credentials, privacy, security, etc… Getting them all right and perfect is expensive (and there are things that you may not know that you should know which really throws a wrench into achieving perfection).
I hate the term ‘good enough’, but it is something that I’ve begrudgingly learned to appreciate as I age. Since I no longer have the time to seek perfection (except on side projects), I practice exercising judgment with bad things. For instance, if your first implementation is O(n^3), then is it bad? Well, sure it’s ‘bad’; however, what if it finishes 99.999% of the time in less than 1 ms for moderately (and unlikely) large n. Pick your priories that have to be perfect (i.e. security), and then learn to manage the imperfections in your product that aren’t as important (i.e. memory footprint).
Exercising judgment requires things that you can compare. The easiest thing for us humans to compare is numbers. Thus: measure everything.
It’s vital to actually finish, and something that isn’t perfect today but good enough is an opportunity. By finishing the effort with imperfections, you can define units of work which can be easily communicated to new hires. These opportunities are great for you to grow as a leader and also as way of bringing more engineering to power to bear on future problems.
The key markings that makes an engineer an engineer is having a discipline about the way you conduct the business of getting things done. There are many ways to manifest discipline. You can record metrics and telemetry to know how code is running in the field. You can have alarms and dead man switches. You can master automated testing. You can manually test everything you do.
Once you have a sense of mastery, the next is building that mastery within a team culture. This will define an engineering team’s ethos for what good is. Now, there will be gaps, and things will go wrong.
It’s vital to be humble and recognize the limits of the human skull. In any engineering team, when something goes wrong then fingers naturally get pointed. Here is the key, this is an opportunity for the leader to illustrate what is going to happen next and how the team culture will change.
I always love it when things go horrendously wrong because that’s an opportunity to do things better, and the key is that you shouldn’t blame the humans. Humans have limits, and the goal is to turn a team into a super human. For an engineer, this is going to be a driver for discipline.
Be kind and nurture an environment where mistakes help the organization learn, evolve, and mature.
If you have an idea about how something should be done, then just do it. Whether sanctioned or not, just do it. If you believe it needs to get done, then just do it. If ___, then just do it.
I’m a huge fan of asking for forgiveness rather than permission. However, this can be a risky move, so it’s best to be secretive until you have something of value. Even then, if it blows up in your face (due to either technical problems or politics), then you still learned a ton of valuable lessons which will prime you for success later.
It’s OK and natural if some days suck, but if most days start to suck, then you are doing it wrong (or… you need to go somewhere else). At the end of the day, you need to have enjoyed a majority of your day.
The job should feel mostly like play.
The product is a kingdom, so learn about every parcel. Pick areas and take ownership (preferably areas that are not already owned and have scary business risk with them). Be the ‘go-to’ person for the various realms of the kingdom. Make sure that when bad things happen (and they will), then you can ride in on your white horse and save the day.
The natural side effect of this is that you own a piece of the kingdom, and you can start to make long term decisions regarding your parcels. After all, you will be the expert on that region of the kingdom.
As you build your empire of knowledge and expand your scope over the product, make sure that you invite, share, and teach others how to tend to it. Hording knowledge is extremely ineffective for both yourself and the company. If you find another empire builder that isn’t inviting, sharing, or teaching others, then invade. It’s risky for your customers to have individuals having complete dominion over critical aspects of the kingdom; after-all, we are human and we die (or go on vacation).
Is simple: put yourself out of a business. If you can mentor someone to take over your role, then you have replicated hopefully everything that makes you great without all the pains.
The person after you should be much better doing what you suffered through.
Instead of complaining, I recommend just fixing things that suck. However, there are situations when that doesn’t work (i.e. major architectural shifts, lots of review needed, lots of redoing old things, lots of things that need to get done which requires resources beyond your own fingers and outside your day to day goals).
Things can suck, and they can suck bad. Rarely is anything ‘perfect’ (see above). An ineffective complaint is “this code all sucks because it isn’t functional/stateless/trivial-property”. An effective complaint contains (a) the problem with strong reasoning and data, (b) the ideal long term solution, and (c) the short term mitigation/solution.
Communicating this effectively will plant seeds which may manifest on their own.
If people respect you, then this can become a roadmap item in the future.
Ultimately, a title is just a string of words to communicate some achievement level. However, there are a few important career milestones to achieve.
The first is being competent, and we like to call this “Senior engineer”. I prefer to think of it as being a practitioner. After a few years of work, you are useful at getting things done. Once you are trusted to get things done as an individual contributor, you can become a team leader where you orchestrate 4-6 people. Now, this is vastly different than being a manager which many organizations get completely wrong. Here, a team leader is focused on a large goal and will work with people within the team. The manager role is to bridge from the higher up and other peers such that the technical leader has full context without the randomization.
It’s important to note that many companies get this wrong. However, when done well, it is very effective.
Beyond being a team leader, the elevated position is to be an organizational leader. An organizational leader leads 4-6 team leads and works with 4-6 peer tech leads in other organizations. At this point, the organizational leader can scale up from 16 people orgs to thousand person organizations with the nature of the technical goals and organizational challenges changing proportionally as well.
The end game is to lead the planet and make things which push the species forward.
Being a technical leader fundamentally requires achieving technical success.
The technical bar is fairly simple to define. Reaching this bar means that you can do the work and ship the products you said you were going to ship. A critical aspect of this is knowing when you are unable to ship and communicate that up. This field is so wide and diverse that it is impossible to a master the universe, but you can master two things.
You can master the basics and fundamentals. These are writing clear and concise code, documenting, communicating what you are doing, working on a team, writing tests, and being responsible to your customers. I think of this mastery as reaching practitioner status, and you can do the work in front of you.
You can master an area of expertise. Mastery here means a couple of things. First, it means being in the know about a bunch of specialized topics and having some deep experience in shipping these systems or products. Second, it means that you can evaluate ideas on a variety of dimensions and engage in meaningful discussion of pros and cons. You need not come up with an industry defining ideas, but you should be able to evaluate the ideas.
Being a technical leader requires agency. Agency is the ability for you to execute on what you believe. The field is wide open, and there are many things to be built. I had a defining moment in my career at Amazon where instead of waiting for permission to build, I went and built. There are multiple ways of achieving agency, and I want to illustrate two methods.
The first way is communicating value proposition. This is where you use a touch of persuasion and sell what you need or want. Software is all about people. If you have a good idea, then you need to communicate it. You should be able to front-load why your idea is good. Communicate the what and why, and educate those around you. This is minimally achievable by writing brief design document with an FAQ and a few pictures; the key to execution is then meeting with people and hashing it out. The goal here is to inspire everyone that you can deliver value.
The second way is to bet your career. You engage on a project, and you are prepared to get fired if it doesn’t work out. This is hard-core mode and mirrors an entrepreneurial mindset. This is not the card to play at the beginning of your career, but this is a card to be played when you achieve critical mass of value to your team. The stronger you build a track record, the more freedom you have to fail. The weaker your track record, the more risk you take on by taking the bet.
A good way to think about this is that you have a karma with the people around you, and you are constantly building it up with wins and success. For instance, if you have deep experience in operating a critical system, then wielding that allows you to experiment in new areas because you have karma to spend. That is, you have immediate value to the people around you that is demonstrated by history.
I caution that spending karma with force is not ideal, but it may be needed. It is definitely needed when your leaders are closed minded, then getting fired is probably an OK outcome and you should experiment regardless.
Since communication dwarfs technical complexity, your inability to communicate the value proposition can hold you back. When you are holding yourself back, you have to decide if the value is worth it for you to make the bet and spend your karma.
If you spend a bunch of karma and execute, then the most important thing is to listen to feedback. If your bet was a success and you have happy peers and customers, then two things happen. First, you get more karma to spend later, and this will help you more down the road. Second, you will have an opportunity to connect your mental thinking with the happiness of the people around you. As stated before, communication dwarfs technical complexity, and understanding how to convert your ideas into value proposition is hard. The key here is to pay attention to what makes people happy. Understanding how people communicate their happiness is the key to understanding how to communicate value proposition.
If the bet was less then successful, then you learn from the failure and understand what feedback makes people unhappy. Depending on the failure, the key here is to listen all feedback and understand the inverse of value proposition.
If you area a leader, then you have influence. Here, what you do and say matters. Real leadership is not a title. Real leadership is doing and dancing in a field, and I strongly believe that you need to be the best version of yourself.
You aim to be a role model. This means that you need to always try to execute in the best way you know how. For instance, if you say that tests are required, then your code should always have tests. The recipe is fairly simple: “If you say that $X is important, then you need to do $X all the time.”
The implicit aspect of being a role model is that you need to speak up and communicate what you think is important. I value testing, and I make this a priority. I do not let things ship or leave my hands without some form of testing, and I communicate this up and out.
Exercising influence in this manners requires building up a set of values that define how you function and how you get things done. Once you have your values, then you broadcast them and let other people use you as a buffet of ideas. We learn from each other, and some of my values came from others. Some ideas, I have evolved from others. Some ideas, I drop and then communicate why I drop them.
The extreme end of influence is to inspire. I find this quote applicable as I am inspired by this quote often.
If you wish to build a ship, do not divide the men into teams and send them to the forest to cut wood. Instead, teach them to long for the vast and endless sea.
The lesson here isn’t to use people as machines or “resources”. The lesson here is that a leader will point and say “hey, over there, it’s pretty awesome. Let’s go there, I am going, who is with me?” and people will follow.
I look at mentoring in two ways.
First, there is the explicit one on one relationship that is intimate. Get to know each other, and talk about stuff. This stuff could be about life, the field, challenges, people issues. The goal is to share experiences, perspective, ideas, and strategies.
Second, there is an implicit apprenticeship. I utilize this on new hires, and I tend to actively lead a new hire project directly with an idea of mine where we work together on all the design details. The goal here is to setup the new hire with a great project with a reasonable scope. The project is probably already designed either in the back of my mind or some short design document, but the project should be a platform to push tribal knowledge asynchronously and get people up to speed with the team.
At the end of the day, mentoring is about helping people grow. A key aspect of this is communicating the growth goals. Ask your mentee how they want to grow, and then help them. You can help them by sharing stories, giving ideas on how to experiment, and asking questions. The key is to make sure a conversation happens, and it is not a one way street.
For the most part, most students are enrolled in school not to enhance their understanding of the world. They are at school to have the good life that is sold on the television. There is a joke, that I recently heard is told around Harvard.
“A” students become professors, and “B” students work for “C” students.
There is a great deal of truth to this, and it saddens me to see parents rush their kids around trying to get them to pass these standardized tests so they can get to good colleges. This hope of getting into a good college will lead to a good job where they can finally work hard to retire and have a good retirement. Retirement, naturally, is followed by death.
Getting good grades is by far the most useless activity that you can engage in, so what is the kernel of truth in the joke. My theory is that C students are abandoned early by our societal machinations, so they gain freedom to fail. A part of me wants to say that not all people are not equipped to deal with the freedom to fail, but I think that is a huge disservice to the species. After all, do you see in the news how many people are dying left and right?
The problem with the B students is that they need a course laid out for them. If something, then good thing. This path is full of busy work, laden with maintaining the status-quo, and laden with being conservative on the one true path.
So, what is the problem? The flaw is that the more you buy into the system, the more risk averse you become. It makes you easily manipulative as fear is deeply rooted into your decision making. Instead, imagine if you realized that occasionally getting an F would make your life better? How would that affect your decision making?
Please do not get me wrong, education is important. The thing that I question is how does one obtain it. The current system, I believe, costs too much and delivers too little.
Dropping out and focusing on business helped me more than any PhD or master degree.
When I think about people, I think everyone has their strengths and weaknesses. Recognizing this, you have two choices. You can grow your strengths or grow your weakness. My opinion is that you should grow your strengths with the explicit goal of becoming a heroic champion of that strength.
This should conjure up the difference between generalists and specialists. In essence, do you want to be a master of one thing or a jack of all trades? What I want to point is that is heroism applies to both. I propose that one should focus on core attributes. For instance, suppose you are good a math. If you focus your energy in just math, then you will become a specialist in math. If, instead, you focus your strengths on reasoning, then your core intellect will go up. If you are good at writing fiction, then you should focus first on communicating.
If you bring up your core attributes, then you can wield them to prop up your core specialty or your general skills. The attributes that I consider to be core are:
These are fairly broad, but they are common to leadership and high levels of functioning.
I hold the view that one should spend a life to become a master of at least one thing (otherwise, what is the point?). Combine this mastery with core attributes, and it makes one full of win.
The folly of ego is that a strength in one area will fool you into thinking you are a master of the universe. Instead, you accept your weaknesses. Realize that your weaknesses are not inherit, but a lack of focus and energy. I remember a colleague of mine once told me that “you come in to work and decide how you are going to fail”. In this moment, I was enlightened. There are many things to do, and so little time. Your weaknesses could be brought up to market quo, but only at the expense of other things and opportunity cost.
If you focus your energies on your core attributes along with a few specialties, then you can utilize your core attributes to help rally troops to cover your weaknesses. For instance, I currently suck at UI design since I’ve spent maybe two hours in my entire life thinking about it. But, I’ve learned what I like and who I can hire to bring my ideas into a nice state.
The end goal of reaching this level is to have life confidence. Life confidence is when you are no longer afraid of the market, labor conditions, or anything. You know that no matter what life throws at you, you can handle it. A hero realizes that all problems of life can be solved somehow.
I made a my terrible standing table. Since I really didn’t want to go to IKEA for a simple standing table (IKEA is like the anti-old-skool store), I decided to make my own. This is an advantage of renting a free-standing house rather than an apartment: you can buy tools and use them. I went to home depot and bought wood, a circular saw, an orbital sander, and some screws. I set out about the task.
Worst table ever. I had a free standing table, but it was kind of wobbly. I could see the joints were not tight. So, I walk away for a week (since I had to go bed and a week of going to work).
To finish it up, I got a belt sander so I could try to even out the legs. Ok, it still sucks. This is not a product that I would want to buy. I see the details, and they matter. The joint work is terrible.
I considered to start over to get the framing and joints perfect. However, I thought about it, and I came to this conclusion: finish. Just finish. So, I got some black stain and I applied after I sanded it down. I put in some braces, and it’s a lot less wobbly now. Once I apply the Polyurethane, it will be shiny and nice. Oh, and I got some feet which I can adjust to the floor.
Suppose I went with my perfectionist gut feeling, I wouldn’t have messed up on the staining nor have overcome other obstacles. If I had started over, then messing up the staining would have been devastating. Instead, I can plan now for version 2.0; and there will be a 2.0 table. I’m going to make a table for the printer. Then, I’m going to make a table for the dining room.
This idea rings true for software development as well. I’ve done a lot of different things over the years. I’ve written mountains of code, and I’ve repeated myself more times than I care to admit. I feel like I should have finished more projects, but I was enamored with the idea of creating something perfect; alas, now I have nothing to show for years of hard work (besides a great job).
The most unfortunate aspect of having ego is that it blinds us to the truth. When ego is engaged, ideas generated are “golden” and “perfect”. What this means is that when your ego is engaged, you will defend tooth and nail a position that is wrong. I’ve seen this happen both in myself and others, and it can be frustrating.
When you realize that you may be wrong, then the best thing to do is to admit that you may be wrong. The way that I do this is to relate to intellectual honesty.
“To be intellectually honest, now that I think about it, this may be problematic because XYZ”
The most important thing to call out to your peers is the data that changed your mind because this serves to educate those around you. Now, if someone presents the data, then the best thing to do is think about it; if it does contradict the idea or thought, then accept the data and move on. If this means the meeting is over, then so be it.
When you realize that someone may be defending a bad position due to their ego, there are two ways to handle it. The first way is to present data that you have, and I do this with a bit of confusion.
“I’m confused; how does this handle XYZ?”
The key is to force intellectually honesty on either side. The second way is to go gather the data and present it, and this serves two purposes. First, it forces you to intellectually honest evaluate their ideas. Second, it enables you to gather the data that may help instruct them.
The extreme case of this is blindness to data. My opinion is that data is king, and people that ignore facts and data should be avoided.
Ego is limiting since it will seek to limit contradictions. A contradiction, in terms of ego, is “I think I am smart” yet “I just did something incredibly stupid”. These events are your best teachers, and if you limit them, then your growth will be fundamentally limited.
My advice is to never be comfortable. Work on things that scare the crap out of you, have risk, and are important. If the probability of failure is small, then do something else. If you want to work on something that is comfortable, then I recommend doing it as a side project.
When you see people being risk adverse, then you have two paths: the path of good and the path of evil. The path of good is to challenge the person that is self limiting. The path of evil is to abuse them to have them work on all the crap work that is easy and risk free. Sometimes, you take the path of evil to frustrate them enough to open the door to challenge them.
“Oh, no one understands my genius” or so it goes. The nature of unchecked ego is to place oneself on a throne of unquestionable awesomeness. “I’m so awesome, and I lack the time to explain to the feeble peasants.” or so it goes. In the worst case, ego leads on to being withdrawn and alone which drastically limits career opportunities (both at a company or as an entrepreneur)
This is tricky. If you are happy in your bubble, then why get out? But, if you are unhappy as the bubble limits your career and increases your loneliness, then the steps are simple: burst your bubble.
The most effective way to do this is to communicate with other humans and work on a team. The trick to bursting your bubble is to realize that if “I am such am awesome specimen of a human being, then it should be trivial to write down and communicate my ideas”
The ethical question is “If someone is happy in their bubble, then who are you to burst it?” This really depends on your relationship to the person, but I generally think the answer is yes unless circumstances make it obvious not to. The key is to lead people out of the bubble by teaching them out of it. That is, look in the bubble. Is their bubble interesting? The worst case is the bubble is boring, and this requires a gentle nudge to say “hey, try this or consider this”. The idea being that boring bubbles need ideas to being interesting. Once someone has developed an interesting bubble, the goal then is to teach them to come out of the bubble. You do this by taking on the burden of communicating and sharing their bubble. You share their ideas while attributing them and let them know that sharing and inviting people into your bubble is ok. You teach them by example.
Volume, Volume, Volume: Beginners know nothing, so should they focus their efforts into trying to build one thing well? I think this is a mistake because their palette is limited. My philosophy is to try lots of things. Have an idea, and then quickly try to realize it as fast as possible. Make lots of stuff. Make lots of junk. Make, Do, Make, Do. Be fearless, and make a mess. Do. More. Make. Harder. Create.
Reserve judgement as creativity is about trying things, then evaluating them. If you have an idea, then don’t judge it. Simply accept the idea, and work on it. Once you realize the idea and bring it into reality, then judge it. Many times, it is easy (and lazy) to have an idea and dismiss it. Instead, embrace it, run with it. The beginners goal is to learn things.
Once you judge something tune your focus. You may realize it isn’t good. That is great! The question is: what matters? This involves seeing what you can measure and then try to maximize that. Suppose you make a game, and it is slow. Focus only on speed. Don’t worry about code quality or other non important metrics. Focus on hacking it until it is a blazing fast example of speed.
Suppose you make something that works well, but is hard to extend? Focus on generalizing, and don’t worry about other things.
Maybe the game you made sucks, try to make it fun regardless of the plugin architecture.
Focusing is about putting all but one way to judge out of view.