Angelina Fabbro is a programmer based in Vancouver, Canada. Angelina has a background in cognitive science, building clever robots and researching what people pay attention to. Her record as a web developer is balanced with modern iOS experience and a keen sense of design. Angelina also both teaches and mentors for the Vancouver chapter of Ladies Learning Code.
Take calculated risks — no risk, no reward.
Embrace failure but don’t let it define you — failure is your tool.
Surrender, fully, that you can’t control everything, or even as much as you pretend you can.
Say no more often than you say yes when someone asks something of you — say no to new projects, when you ask that of yourself, if you’re in the middle of enough already.
Say yes to the things that make the world a better place for everyone, not just the people you like and the people similar to you.
Spend time around people who are not like you. Go spend time with people of different backgrounds to you across race, class, gender, sexuality, ability, beliefs and ideals. Never become insulated from these experiences.
Your career is a vessel for your well-being — if your job isn’t making you happy and healthy and/or doesn’t quite meet the requirements you need to be happy and healthy, find support and transition to another path.
Having more money won’t make you more happy. It will give you more opportunity. Use it to become better, stronger, happier, and then to enable and inspire others to do the same.
Volunteer and give back. Always.
Playing video games, resting, visiting friends, watching movies — all the things you do to unwind are NOT A WASTE OF TIME. They combat burnout, and you need that time otherwise the things you make and the tasks you do will probably not be as good as if you were well-rested and inspired.
Take burnout seriously. Don’t pretend like it can’t and won’t happen to you.
Your emotions are important. Give them space, feel them, embrace them, and create from them — but do not let them rule you, and do not let them participate in decision-making. 90% of the time that is logic’s domain, and emotions often don’t compliment logical thinking well. You may read this and think, ‘But what about love?’ — a good question. A post for another time, though.
When I write these things, know that I’m not preaching that this is the Absolute Path to Greatness or something as trite and presumptuous as that.
It’s just a list of things that I’ve been chewing on this past year, and we’re in that part of the year where self-reflection is imminent and plentiful. That’s all.
It’s the advice for myself I want to take. I don’t always follow my own advice, though, so sometimes I like to codify the things I’m thinking about so that I can point back and see where I went wrong, or right.
The last few pastries have tried to examine some common ways we tend to get in the way of ourselves when trying to get better at programming. The last one examined procrastination, which is a common problem for a lot of intelligent and creative individuals. In that post, I gave an example list I had constructed for myself of all the ways and reasons I could possibly have for avoiding completion of a task. One of those items was ‘fear of success’, and I noted that particular item required some extrapolation.
In my experience, I have found a lot more written about the fear of failure than the fear of success. Does this truly represent the proportion of people affected by either? Or could it be that fear of success is a more controversial and perhaps less understood phenomenon? Could it be that as a culture we assume nobody could be afraid of success and that failure is, instead, more important to address?
Once upon a time, years ago, I knew someone who never, ever finished a project. They had transferred three times from university to university, always changing their degree plan short of actually ever completing a degree. When confronted about this, the excuse was what you might expect: they had simply changed their mind about what they wanted to do. With only a semester or two left in each case, at most a year of classes in one instance, I found this hard to believe. Especially as this happened over and over. However, I gave this person the benefit of the doubt.
Over the years I noticed similar patterns. Eventually, this person never finished any degree and instead moved on to the idea of starting their own business. With another friend of mine, they cooked up an idea that had the same fate as this person’s schooling, and after it, another. Each business idea would spool up, and then before the product or service could really shine, this person always found some reason to shut it down and move on. This was frustrating as I saw a lot of promise in some of the ideas and strategies; I could have seen several of them become legitimate startups. Many of the ideas were niche and the ideas to accommodate them were innovative. Still, they never followed through and I didn’t understand why. I didn’t understand why someone so bright and creative would get so close to completion, so close to success and then just walk away leaving only a paper-thin excuse behind.
I remember the day I thought to myself that they may be afraid of success. We were at my house and I was listening to them hatch another plan with the same assurances and the same renewed vigour for it that came with every new plan. I interrupted this person, which in retrospect I admit was rude, and I blurted out,
“You know, I really think you might be afraid to win. I think you’re afraid of being successful, and all the responsibility that you’re not actually prepared for that might come with it. Every six months, every year that passes you’re onto something new. Nothing ever gets finished. No risk is actually taken, and I think it’s because you’re afraid of success more than you are of failing, because you had this pattern in school close to graduation before you ever had it in business. You’re doing the same thing right now.”
Predictably, they did not respond well to this idea. Sometimes people are not very good at taking observations others make in stride. Eventually, one day, this person did admit that perhaps that could be a part of why they do what they do, but it was clear they didn’t want to talk about it very much out loud to another person if that was true. I decided to respect that suspicion and let it be. Unfortunately, we do not keep in touch anymore, for reasons that are unrelated to this encounter. However, I do know what this person’s doing because the internet affords me the privilege of being able to keep up on old friends.
For several years now this person’s been working on a web application, and in all that time it’s never come out of beta. I’ve seen it, I’ve tried it, and what it definitely needs is actual non-beta users to get any better. Nothing replaces user testing. Nothing replaces production-level mass-user testing on a site you hope to reach a large audience with. I can’t help but suspect they know this, and that being in beta forever is another manifestation of their fear of success.
Maybe you are afraid of releasing your code open source because you are afraid of having to maintain it, especially if it gets popular. Maybe you are afraid that your code will be popular, and then attract a lot of scrutiny. Maybe you are afraid of showing your boss how you optimized the entire order-taking system of your business because then he’ll expect that same level of ingenuity and performance as a baseline and you don’t think you can keep up consistently long-term. Maybe, just maybe, you’re afraid of success because you don’t know what it looks like, and so maybe you’re afraid of the unknown. You might even have both a fear of success and a fear of failure, which may make circumstances even more challenging.
At least, with failure, you can kind of guess at what failing will be like most of the time. You can say that if you don’t complete a feature on time, you may get in trouble or even lose your job. If you don’t pass an exam, you could fail a course in school. We spend a lot more time focusing on the consequences of failure than on the consequences of success, and this is a problem.
When it comes to the fear of success, there is only one way to deal with it that I know of: take the risk. You know you have something good but you don’t know what that will mean for you in the future, but if you don’t take that chance then it may pass you by and the opportunity will be lost. Life is for living, and it is all too short. If you don’t take the chance, you risk a life filled with regrets. You risk a life with promise that was never shared with the rest of us, the world, and that is a sad thing. We want your greatness, so bring it out, and I promise you’ll find others like you that will want to help you navigate whatever comes next along the way.
Yeah, sure — I don’t know what will come next for you any more than you do, but the same is true of any day you live, and any path you choose since we cannot predict when your life may be over from circumstances other than natural causes. Your projects are no different than a day in your life so to speak, so take the plunge and see what happens. It’s worth the emotional risk.
In one of my previous pastries, I talked about how you should always ask yourself why you do the things that you do. The premise of this was that if you consistently question yourself, you develop self-awareness and hopefully an understanding of your behaviour. With this information you might be able to change or accommodate your behaviour in order to more efficiently achieve your goals.
One of the questions I posed in that pastry about myself was ‘Why do I procrastinate the things I love?’ Sometimes, I will deliberately ignore or avoid a task or project that I’m actually in love with. It’s paradoxical in nature. Once I started to pick apart the behaviours and found my way inside their pattern, a whole lot became clear.
This is what behaviour would occur:
I came to loathe this pattern once I recognized that particular things weren’t getting done. It didn’t seem like there was any reason that I did this, and it stressed me out that I didn’t understand my own behaviour. Surely there must be a reason. I never like it when my behaviour does not make rational sense, which is frustrating because I am predisposed to be irrational as frequently as the next person.
To skip ahead of a lot of self-inquiry and discussions with peers who confront this same issue, I compiled a list of possible reasons for my procrastination:
There are probably many more items I could add to this list, but I’m merely speaking from the anecdotes of my own experience as I usually do when I compose these doughnuts. Sometimes more than one of them apply to me at any given point. Another important thing I recognized is that my level of distractibility and procrastination are very correlated. It seems that this is often the case for other people too.
Over the years people have recommended a lot of different books to me on ‘overcoming procrastination’ and I found only bits and pieces of them marginally useful. Many were patronizing and offered little in the way of substance to help me do away with this behaviour. In fact, the one thing that bothered me the most was that these books assumed that this behaviour could be ‘cured’ at all. Some habits are difficult if not impossible to change, and I’d been operating this way since I was a child. The habits that start young are the most pernicious to erase when you try and get at them. It wasn’t for lack of trying, in the case of procrastination — society has made it very clear that procrastinators must be lazy, ineffectual people. I certainly didn’t (and don’t) want to be a lazy and ineffectual person. At some point I decided to stop making myself feel guilty. Plenty of successful people I admire admit to habits of procrastination, and they still achieve and accomplish great things. So what’s the catch?
So say it out loud with me if you’re frustrated with the shame of procrastination and the impetus to combat it:
“I’m probably always going to procrastinate, so instead I’m going to make it work for me.”
So what does this look like in practice? The first step is probably obvious, and it is to identify the reason that you are procrastinating. This is the hardest step because it means being totally honest with yourself about your behaviour, and if you’re not used to that you can and will dance around the reason. It helps to have a list like the one I’ve compiled above, you’re welcome to use it as a starting point or generate your own. Some people will tell themselves that they really and truly can’t find a reason and that this has no cause. For most people I think this means they have not been honest or given enough time to figure it out; although I bet there are a few outliers who genuinely struggle with biology that gets in the way too. The most important thing? Be honest with yourself.
Sometimes identifying the reason is enough. I know for myself, in the case where I recognize that I feel overwhelmed by a project, that the next step is to break it down into smaller parts. Then I can take on the larger project piece by piece. Sometimes once you know the reason, the path becomes clear. But often we don’t know how to break down a task further, or maybe that’s not what is making us procrastinate.
So, instead, do the following: procrastinate your task with another task that you had previously been procrastinating. Repeat as needed.
If you have a deadline or a set of deadlines you are working with your cycle of procrastination will probably need to be accelerated or altered, as it might be under time pressure. Usually the stress of the deadline means that you complete the task very close to the deadline. This is dangerous as it means you may compromise on quality. I actually recommend procrastinating projects often and early. Cycle through them, never get bored, and always be looking at the task in front of you with fresh eyes.
For personal projects or anything outside of your employment where a deadline is not required, do not set a deadline. It’s tempting to set deadlines on personal projects, because haven’t we been told our entire lives that every goal needs to have one? What if instead of this, you simply say to yourself,
“I want to accomplish this task, and I know I will eventually, and I’m okay with the fact that I don’t know when that will be. I’ll finish it when I’m excited about it, and this process may not be temporally contiguous.”
Then, iterate. When you hit a block with a project, switch to another one. Don’t guilt yourself over it, don’t hesitate, don’t tell yourself that ‘this isn’t how normal people operate’. Yes, it is. Lots of us do it. I’m not going to sit here and have someone tell me that this way of operating is bad behaviour. If you’re producing and you complete things eventually, then who cares? Don’t let anyone else judge you, your process is your own, and if it works? It works. That’s all that matters.
In the case of fear of success or fear of failure, things can get very ambiguous and this process might break down for you. I don’t have any simple answers for you on how to deal with these in the framing of this strategy. You need to keep asking yourself ‘why’ and try to get at the core of how you are feeling, which in turn will probably help you figure out how to break down dealing with yourself, which in turn may deliver you with something actionable. This is a topic that warrants an entire pastry all to itself, and these are things I will likely write about in future cupcakes.
Embrace your behaviour and make it work for you. Procrastinate on.
This post brought to you by a very overdue submission after way too many days of procrastination and reflecting on said procrastination. True story.
In my recent article on The Pastry Box I specifically chose to use the term ‘impostor phenomenon’ instead of ‘impostor syndrome’ throughout the entire article. In most of the peer-reviewed research I read I saw this reflected as ‘impostor phenomenon’, but it has been pointed out to me that ‘imposter syndrome’ is used fairly often to describe the same thing.
In fact, the latter is used colloquially far more often than ‘impostor phenomenon’.
I made the choice to use ‘phenomenon’ because the word ‘syndrome’ carries with it a host of negative stigma that is wholly unproductive. The term ‘phenomenon’ in this case is at worst a fairly neutral term. Whether or not we recognize that ‘syndrome’ is, in fact, a clinical term that could apply here is orthogonal to the impact that using the term has on those experiencing these feelings, emotions, and experiences.
It has negative stigma. Negative stigma is not helpful to anyone.
Whether we like it or not, words take on cultural additives as we use them. A word may begin it’s career as an idea meaning one thing, but eventually evolve to mean multiple things or something else entirely.
We are all very impressionable. Unconsciously so, even those of us who like to think that we have a thick skin. You cannot escape the unconscious processing of subtle meaning, if you think you can you are a fool. If anyone is interested in talking about this particular point — there is a host of cognitive science research waiting for you.
That being said, the words we use are immensely important, and so I implore you to use the term ‘impostor phenomenon’ when describing these experiences. It makes a difference.
Whenever I hear someone complain that advocates of careful language are trying to be ‘too politically correct’, ‘sugar coated’, or ‘too nice’ I feel sorry for them. I feel sorry for them because they don’t understand the difference these things make, and worse they don’t understand how vulnerable they are. They lack the self-awareness that will set them free if they’re ever upset about something someone has said about them.
“Sticks and stones will break my bones but names will never —”
Wait, wait. I know this one. Sticks and stones will break my bones. Those will heal up, because biology can do wonderful things like that. But words? “Names will never hurt me” is usually how the rest goes. Those words can still be with you months, years, decades later. They can torment you when you’re trying to fall asleep, apply for a job, or make a new friend.
Words have power because they have meaning: treat them with respect, and treat others with respect accordingly.
If you write code, if you participate in the act of programming, then you are a programmer. We can add a clause to this that suggests regularity — someone who programs often is a programmer. That’s all it takes to be a programmer. It doesn’t matter if you’ve just started and worked your way through the fundamentals like control structures and taming functions. It doesn’t matter if for some reason you don’t feel like a programmer. It doesn’t matter if someone pays you or not, unless you really find it important to be a professional programmer. If you program and you do it over and over, you become a programmer.
Last week I had the privilege of being amongst the speakers at JSConf 2013. The best part about this particular speaking opportunity was that I was able to give a non-technical talk about programming that I’d wanted to give for a long time. It was a culmination of all the things regarding learning to program that I’ve talked about here on The Pastry Box stitched together with further anecdotes and advice. It talked about cognitive biases and tried to convince people to get their biases out of the way so they could realize their potential. One of the slides in my presentation addressed impostor syndrome (known as impostor phenomenon in peer-reviewed, formal research) as it relates to the craft of programming, but really the point I was trying to make could be applied to anybody in any field.
Impostor phenomenon, explained simply, is the experience of feeling like a fraud (or impostor) while participating in communities of highly skilled participants even when you are of a level of competence to match those around you. Impostor phenomenon is highly correlated with individuals who are successful; arguably success here means success as perceived by others. The important thing to note is that this experience isn’t isolated to people we perceive as experts, only that it is a counterintuitive notion: one might assume that as they develop their skills in a craft further that their confidence should increase and their insecurity about whether they are good and whether they belong would fade away. It turns out that this is not the case for a lot of people.
I found myself wondering if my talk was going to be all that useful to the people I perceived as experts; I questioned whether or not the smart people I admired that I knew would see it were going to find value in this thing that I had made to share with everyone.
I gave the talk, and afterwards several of them thanked me for that slide. Some of them my heroes, they took me aside and confided their thanks. They confided their relief.
In the end I wasn’t shocked that the successful people I admired had experienced impostor phenomenon and talked to me about it — I was shocked that I somehow thought the people I see as heroes were somehow exempt from having it. I did the one thing I didn’t want to do: make that assumption about anyone.
We’re all just doing the best we know how to when it comes to programming, it’s just that some people have more practice coming across as confident than others do. Never mistake confidence for competence, though.
I’m just going to put this out there: to anyone of any skill level who reads this, if you’re ever feeling like you’re a fraud in your field; if you ever feel alone or if you worry that you’re not smart enough or good enough as the next programmer, just come talk to me. I’m a busy person by design because I can’t stand to be idle, but I’ll make time for you because feeling this way is isolating, lonely, and not constructive. I think of all the missed opportunities I let pass by all because I was worried about making mistakes, not being perceived as an equal by my peers, and all the code I never wrote just because I was intimidated by all the great code and smart programmers out there.
I want to listen to what you have to say, to tell you that you’re not alone, and that your heroes are human too just like you.
Last month I baked a strudel about how to know you’re not a beginner anymore. I found this exceptionally useful as a kind of lower-bound I could put on my skills and knowledge; I could say that there were topics I could move forward from and thus move towards more advanced material with confidence. This month, I’m baking a cookie about how I know that I’m not a master at programming. In fact, I’d even go as far to say that there are no masters.
There is no such thing as a grand ultimate master of programming because the goalposts will always keep moving. If we were to take the top ten percent of programmers, we could say that those programmers are probably experts. We would still have the problem of defining what criteria includes people in that ten percent, which is an altogether different matter. But a master? The term ‘master’ in the context of ability is usually reserved for someone who has studied an art or science so thoroughly that they have complete knowledge and skill over said art or science. When it comes to programming, there are no masters because the landscape of programming changes dramatically as new technology is forged.
There are always new tools. There will be new languages. The hardware will change. The software will have to adapt. You will have to change. You will have to adapt.
Sign of Programmer Expertise #1: The programmer understands that the learning will never stop and is at peace with how quickly the tools and landscape change.
The expert who you look up to — you know the one, they’ve written that sweet library you use so much, and you’ve read all of their books — cannot and should never halt on the notion that they have achieved mastery. Programming will move on without them. Maybe they’ll have mastered programming circa the year 2013, but the rest of us will go on without them if they stop there.
So what about that top ten percent? We know it is unrealistic to say we will be masters of this domain. We made peace with that at the end of the last paragraph. How do we approach criteria that describes someone as an expert programmer? The dialogue is ongoing, and I hope that through it we’ll eventually be able to convey to those who want to learn programming the kind of expectations they have to meet to be the best of the best.
Sign of Programmer Expertise #2: If you are an expert at programming, in at least one language you must be able to code as though you have a gun to your head, without a language reference.*
I know what you’re thinking, that most programmers always have a browser tab open with an API or language reference. Nobody actually codes without at least some of that stuff in their day-to-day job. I know I do. This makes sense for when you are trying to make something for someone else and you are on a budget of time, money, or both. Often it makes sense for you personally too, when you’re on your own time making your own wonderful thing. Because you value your time, you want to have all the resources you need so that you don’t have to remember the name of a function that you’ve forgotten while you remember the essence of what that function is supposed to do. You want to accomplish building something for yourself in a reasonable amount of time.
This is good for building things and shipping them, but what it’s not good for is your mastery of programming.
This may seem in direct contradiction to what I said last month. In my last pastry, I explained that you have to be able to program in different languages than the one you are most comfortable with to say that you really know programming and not just the language. This is true. However, this is like saying that if you are learning to swing a sword, you should be able to use almost any sword. There are differences between a broadsword and a rapier, but by understanding the basics you can probably figure out how to use each reasonably well. Despite this, a swordsperson probably has a preferred type of sword, and since there are all subtle differences between them the swordsperson will probably only be able to become an expert with one or two. The same is true with programming languages. While you can broadly apply your skills to any language to create something, it is the concise practice of a few languages that will yield you the most satisfying results.
Sign of Programmer Expertise #3: The programmer is not merely satisfied with solving the problem, they insist upon solving it in an efficient and robust manner.
I’ve had so many people ask me, ‘how do I know if my software design patterns are good, and how do I measure that? ’. Write tests. Measure execution time, function complexity, memory usage, and whatever else you can think of. Benchmark your code against other code. If you can balance your optimizations with code readability, then your design pattern is probably pretty good. The numbers won’t lie, so stick to those and don’t worry about much else.
Sign of Programmer Expertise #4: The programmer knows how their parser/compiler/interpreter works. Intimately.
The programmer who wants to get better at designing software will inevitably get to a point where they can only optimize so far without an understanding of how their language is parsed, processed, compiled, etc. To know the nuances of how the machines speak your language is as big an endeavour as learning the language itself. It will require you to think about your language by picking it apart instruction by instruction to see how it was designed. At some point, you should aim to write a programming language or compiler/interpreter just to understand what the designers of a language or compiler/interpreter had to consider when making the ones you work with every day. You’ll understand the concessions and caveats that cause the quirks of your language that you never had reason to understand before. This will help you learn your language inside and out — I mean you will literally know it’s insides.
Sign of Programmer Expertise #5: ???
As I’ve mentioned before, this is an ongoing dialogue. I’m hoping that the few ideas I’ve exposed here are enough to get you thinking about where you want to go next with your programming skill, and that someone out there will tell me what the #5, or #6, or #7… in this list should be. I have no idea. I’m just doing the same thing that the rest of you are doing; I’m trying to navigate my way through the ridiculous amount of information available to pick and choose the most reasonable course for success. So, if you know what comes next — tell me. I’m all ears.
*Baker’s note: Please don’t ever, ever put a gun to your head even as a joke.
When you are not programming, you are a programmer still. It doesn’t leave you.
When you walk down the street after work and you leave your computer behind, your analytical mind stays with you. If you really want to get better at programming, start finding ways to solve the same kinds of problems you see in your code everywhere else in your life. Probably you are solving many of them already every day and you don’t even notice it. The last time you travelled to complete errands, did you try to take the route that you thought would take the shortest amount of time? Do you try to do your dishes while you have a load of laundry in to parallelize your household tasks? Have you ever followed an algorithm of pictographs to assemble IKEA furniture? Have you ever played a video game and tried to find ways to get the highest score? If we are aware of our penchant for problem solving, then we can embrace it. Good problem solving is at the core of good programming practices.
Always ask why about everything in front of you. I think this is something we are told to do as kids, but as adults many of us become a little arrogant and pretend we are beyond needing this skill. We become smart adults doing adult jobs and we pretend that we know enough and get lazy and we stop asking why to the little things we take for granted. Why do the doors on our office building push inward instead of pull out? Why is the elevator slow — how does it make its decisions about what floors to stop on? Why did the designer of that poster use that particular typeface to convey their message? Always ask why, why, why in and out of your domain. Ask why in some of the most unfamiliar situations and then try to use your reasoning and other programmer skills to come up with a solution. It doesn’t matter if you ever know what the right answer is, only that you’re making an effort to try and solve the problem for yourself. Have fun with it and be creative, and find friends who take pleasure in this pastime as well. You’ll end up having interesting conversations that lead you back to working on your problem solving skills.
Strive, with consistency, toward self-awareness. I mean this in a very practical and pragmatic way, not in a new age fluff kind of way. This is basically a different application of the previous point of asking why. In the previous paragraph, I explained that it is important to ask why about the world around you. Perhaps more important than that is asking why about yourself. Why do I like to play the piano? Why do I procrastinate the things I love sometimes? Why did I write an email I sent in the tone that I did? Even the act of selecting what to wear in a given day is a design problem waiting to be solved depending on who you expect to see and what role they play in relationship to you. Pretend you are an anthropologist specializing in the study of you, and ask why, why, why. You will understand your own patterns of decision-making, and eventually your own cognitive biases. You will understand why you do the things that you do and that will include why you program the way that you program.
When you question everything, you find the places in structures and organizations around you and within you that can be improved, and from that comes meaning and purpose when you are rewarded by that awesome feeling of solving a problem. When you come back to the computer you will have better questions to ask that will make you a better programmer.
This pastry box cupcake is dedicated to Natalie Goldberg, the inspiration of which is taken from the first two sentences of her piece “Be an Animal” in Writing Down the Bones — the best book on writing that I have yet to read.
One of my favourite things about programming is that the code doesn’t care who I am or what I do with it.
The code is inert until I give it purpose. When I’m writing code, I’m in charge. What goes on is between me, my compiler, and nobody else.
Whatever you create in your development environment on your computer is private and yours alone until you make it otherwise. Nobody else knows what you’re writing; this is between you and your compiler*, and all the compiler cares about is whether or not the program runs. This is a tremendous sort of freedom.
Beyond that, the only accountability you have is to yourself in the early stages of writing a feature or program. The only person there to judge what you write is you. Forget about what anybody else might think; know that the code itself has no opinion of the matter and experiment to your heart’s content. Treat your development environment as a playground when you’re just beginning something new.
I have a lot of people asking me how to tell if their code is good when they’re just starting out with programming for the first time. If you worry too early about whether or not your code is ‘good’ before you even have something working, you’ll be wasting your time and sometimes you won’t even get to programming. You’ll spin your wheels and doubt every line you write or don’t write and eventually you are beating yourself up about code you haven’t even written yet. You’ll procrastinate while you worry about details that don’t matter, and then you’ll wonder why programming is so hard. It’s not hard, but you’re doing things in the wrong order. Your desire for goodness is healthy but the satisfaction of it must be delayed.
Get it up, then get it right.
When you’re just starting out—whether you’re learning to program for the first time, or maybe learning a new trick for your trade—you should measure your success by only one criteria:
Does the program do what I want it to for the end-user? (If you’re a beginner, then this is probably yourself.)
And that’s all. If you can answer this question with ‘yes’, then what you are making is good. Don’t worry about what anyone else might think about your code. Don’t even worry about what you think of your code yet.
You don’t have to show what you’re making to anyone until you’re ready, if at all. Get it out dirty and fast and messy if you need to, with passion and without remorse. Nobody has to see your first draft. A novel is not written from beginning to end and then shipped to the publisher without being edited or revised. Code is not written once and then deployed to the users without testing and iteration. Write something, anything, and then come back to it; put your ego aside so that it’s just you and your creativity and your fingertips.
* Note that for all intents and purposes in this piece, ‘interpreter’ can be substituted for ‘compiler’ to reflect your language of craft accordingly.