--- /dev/null
+BUILD = build
+BOOKNAME = the_mediocre_programmer
+TITLE = title.txt
+METADATA = metadata.xml
+CHAPTERS = intro.md chapter01.md chapter02.md chapter03.md chapter04.md chapter05.md chapter06.md epilogue.md appendixa.md
+TOC = --toc --toc-depth=2
+COVER_IMAGE = images/cover.jpg
+LATEX_CLASS = book
+
+all: book
+
+book: epub html pdf
+
+clean:
+ rm -r $(BUILD)
+
+epub: $(BUILD)/epub/$(BOOKNAME).epub
+
+html: $(BUILD)/html/$(BOOKNAME).html
+
+pdf: $(BUILD)/pdf/$(BOOKNAME).pdf
+
+$(BUILD)/epub/$(BOOKNAME).epub: $(TITLE) $(CHAPTERS)
+ mkdir -p $(BUILD)/epub
+ pandoc $(TOC) -S --epub-metadata=$(METADATA) --epub-cover-image=$(COVER_IMAGE) -o $@ $^
+
+$(BUILD)/html/$(BOOKNAME).html: $(CHAPTERS)
+ mkdir -p $(BUILD)/html
+ pandoc $(TOC) --standalone --to=html5 -o $@ $^
+
+$(BUILD)/pdf/$(BOOKNAME).pdf: $(TITLE) $(CHAPTERS)
+ mkdir -p $(BUILD)/pdf
+ pandoc $(TOC) --latex-engine=xelatex -V documentclass=$(LATEX_CLASS) -o $@ $^
+
+.PHONY: all book clean epub html pdf
--- /dev/null
+This is the (work-in-progress) text for the upcoming book "The Mediocre Programmer".
+
+Released under a CC-BY-SA 4.0 International license.
+
+(Uses Pandoc Markdown Template / Makefile from https://github.com/evangoer/pandoc-ebook-template)
--- /dev/null
+# Appendix A
+
+Write down my own journey through programming?
--- /dev/null
+# The Journey of the mediocre programmer
+## How we got here
+
+You have your own unique story of how you got here as a programmer. Whether you found out about programming as a curious child who wanted to see what the computer could do, or as an adult who heard that there were these things called computers that you could program, you had a journey to get to this point. And you learned a certain amount to get here. You spent your free time learning how to code or you were fortunate to be able to work on it as part of your job. You went to school to learn more about programming or you took training classes. You bought books or read articles online to learn more about programming. Whatever the path you took you started the journey as a programmer.
+
+And now you feel stuck.
+
+You look around and wonder if you'll ever know everything that you should know. You read an article on a site and your interest is piqued. A friend online mentions this neat thing that they've found and expects that you should learn more about it. Your colleague found something that seems to solve the issues you're having at work and now you have one more thing to learn. Whatever it is there is now a gap between the you that exists today and the you that feels like you are incomplete without learning this new thing.
+
+Perhaps you're seeing this new thing show up in job postings with a minimum of 3+ years of required experience and you're wondering how anyone would have that level of experience yet. Or you chose to ignore that thing for a while and now it's become a driving factor in your domain of work. And now you look over the horizon of where you feel you should be and you see the gap in between where you are and where you think you should be.
+
+## The Gap
+
+I've chosen the word "gap" to describe the difference between where you are now and where you think you should be for good reason. A gap tends to be something imposed by others, whether by force or by neglect. If you have a gap in a fence it means the fence seems weaker because of the missing slats. A gap can also be something that one would need to be aware of. "Mind the gap" is a phrase that was coined in the late 1960s by the London Underground to warn folks about the space between the platform and the train cars that could lead to an unsafe situation.
+
+The gap in this case is the distance in our current abilities and where we think we should be. Sometimes they are self-imposed but more often they are externally imposed. Often they are the result of a changing industry or changing priorities and it is our job as programmers to adapt to those changes.
+
+But change can lead to stress. Stress is prevalent in programmer circles because things are often changing. What worked on Friday afternoon can be different on Monday morning because of a small point release in a library that we were using. Or our development machine was upgraded and now our code has new bugs to fix.
+
+Change can also come from outside of our domain. Our community of developers might move on to a new technology; whether that is because of professional reasons or personal reasons. We might no longer get the support we need to do our jobs and be faced with the prospect that we too need to update our skills or be left behind in an abandoned community.
+
+Not all change is because of bad events happening. The software that we use could have very good reasons for changing. New features can be introduced that require new ways of thinking about your code.
+
+But change requires time and effort in order to adapt to it. The gap can only be closed if we have the resources and time to work on it.
+
+## Closing The Gap
+
+I'd love to tell you that there's a way to close the gap; a way to say you've learned it all and can feel confident that you have mastered programming.
+
+Sadly I haven't found a way to close that gap.
+
+You can keep learning everything there is to know about whatever topic you've chosen to learn. You can take every course available. You can attend every talk and colloquium, read papers about the subject, and even do your own research and you can still feel like you haven't closed the gap.
+
+So if there's no way to completely close the gap what can you do?
+
+There's three options available to you:
+
+The first option is to not try. Realizing that there will always be more to learn can be disheartening so it's easier to just tell yourself that you'll never be able to close the gaps in your knowledge so why even bother with it.
+
+The second option is to try and become frustrated when you realize how much further you have to go. You'll grab every book, blog post, paper, video, or what-have-you to try to learn the topic and then realize that even with all of that you have a finite amount of time to learn the topic. You'll get frustrated that you didn't figure out that you needed to close this gap sooner and you'll look over your progress and see how much further you need to go.
+
+The third option is the more measured approach. You'll start small with small tasks and work your way toward the goal. Rather than look at the gap as something to be closed you'll realize that you can't know the totality of whatever topic you're learning and instead enjoy the knowledge that you receive in its pursuit. You'll keep a steady pace toward learning as much as you can but instead of lamenting that you didn't start sooner you'll be glad that you started at all.
+
+Of these three options the first and third are the ones where you'll find the most contentment. The first option (not trying) allows you to sit with the knowledge you have. But there's a downside to just staying in place. Our industry is constantly changing and technology continues to move. What used to be the norm becomes legacy and what was just around the corner becomes the thing that is in demand.
+
+One of the most useful skills of a developer is the ability to adapt to new technology. As our technological environment changes our ability to adapt to those changes allows us to continue on as developers. Faster machines, different technologies, different devices, different requirements; each of these things brings us exciting challenges if we recognize them. But they also take time to learn and create gaps in our knowledge. So relying on our previous knowledge to carry us through these changes isn't going to be enough. We're challenged to adapt to the new surroundings.
+
+The second option (becoming frustrated) is the least optimal path forward. Trying to learn quickly by grabbing every available resource and jamming it into our brains is a way to frustration, fatigue, and burnout. Many developers try to do this because they see they need to adapt to the new environment but it's difficult to make sweeping changes all at once. And measuring your progress by how much further you feel you need to go means you discount the progress you've made.
+
+Of those three options it's the third option that makes the most sense. Taking a more measured approach to closing the gaps in our knowledge allows us more joy in our learning process. By breaking down each of the steps on our journey we give ourselves little wins along the way. Instead of expecting a grand transformation we allow ourselves gradual changes and mutations to adapt to our environment.
+
+With this measured and gradual approach we also gain the wisdom that gaps don't have to be closed. We can allow ourselves to keep learning in the areas that we need to and gradually build up our skills. We can realize that closing the gap is an illusion. We can only become more expert in whatever topic we chose to learn.
+
+## The Journey is the Reward
+
+The secret to moving forward in our journey as programmers and developers is to realize that each step we take along that path is valuable and worthy of our attention. Just because we haven't learned the latest technology in a fortnight doesn't mean we should give up trying. Nor does learning a technology only to watch it be completely overshadowed by something else mean that our learning time was wasted. Every challenge we face, every technology we learn, and every hour we spend coding is another step on our journey to becoming better programmers. Each mistake and wrong turn introduces us to opportunities to learn from those mistakes and grow as programmers and developers. There is no perfect path toward becoming better at this stuff, and even if there were I'm sure we could point to any point in our past and say that it was less than perfect. Carving the perfect path from where we are to where we wish to be is not possible. Worse, it is an illusion that keeps us from moving forward in our daily practice of programming and developing. It may seem trite to say "the journey is the reward" but each day we work as a programmer and developer is one day closer to shoring up those gaps in our knowledge and becoming more content with how our skills are growing.
--- /dev/null
+# Traveling Companions
+
+## Famous Coders
+
+Throughout computing there have been folks who have demonstrated amazing coding abilities. They're in the pantheon of computer programmers: Ada Lovelace, Dennis Ritchie, Rear Admiral Grace Murray Hopper, and so on. We also have developers in our own communities that have a certain celebrity status, whether they're the folks who wrote the language we currently use, or the folks who maintain the operating system we use, or someone who rose to prominence in our chosen community. It can feel a little intimidating when we compare ourselves with these folks. After all, whatever we're currently working on might not measure up to whatever they have done. Worse, we may be working on something similar and feel like whatever we're working on will never measure up to those folks. We may even be friends with coders who seem to figure out things much quicker than we can and marvel at how they seem to have this body of knowledge that feels impossible to attain.
+
+## Backstage vs. performance
+
+One of the best pieces of advice I received about comparing ourselves to others is realizing that you're comparing your backstage to their performance. The metaphor draws from the theater, where performers know every thing that isn't right about their own theater-group's performance and unfairly compare it with someone else's finished performance. How this relates is that we tend to compare all of the things that we know (the long hours of unproductive coding, the struggles with learning, and so forth) with the finished product of someone else. We don't tend to see their struggles with getting things to work, or their countless hours making crappy things before they managed to make something that was much better.
+
+## The lure of the post-mortem
+
+There's a tradition in some programming projects (especially game development projects where there is a clear end to the project when it ships) of doing a post-mortem on the project. What the post-mortem does is allow the developers of a project to state what went right and what didn't go right. The better ones tend to be frank accounts of the successes and failures of a project.
+
+The post-mortem can be a fascinating look into the development of a project. I've found myself reading a lot of these looking for insights into the development process.
+
+But there's a subtle trap in the post-mortem: they're a recollection of events from a vantage point of a successful (or unsuccessful) project. They're from a vantage point of someone who has made a thing, and it was successful enough that you are reading about that project's ups and downs. They're written from a vantage point where the success of the project is a foregone conclusion (or the vantage point where the project is was important enough to document why it was a failure, or didn't live up to the expectations of those involved). It can give you a false-sense that what you're working on is not as important as the things that other people are working on. But we don't know the importance of our project in real-time. It may never see the light of day or it might be something that changes the world. We can't know that while we're working on it (though we can have a sense of whether or not we _feel_ our work is important or not).
+
+There's also the tendency in post-mortems to have a bit of hindsight about them. Things that were clear and definite in the moment might not make as much sense with the benefit of future-understanding. There's also selective memory where something might not be remembered with as much clarity when looking at it from the vantage point of a completed (or failed) project. Statements like "we knew this wouldn't have worked" from the vantage point of hindsight may have been "we wanted to try to see if this would not work. We were convinced it wouldn't work but we tried anyhow". Consider anyone writing about their past as an unreliable narrator. True, they may be the most experienced and knowledgeable narrator we have, but they are generally not an outside perspective on whatever they were creating.
+
+There's nothing wrong with reading a post-mortem about a project - we can learn a great deal about how a project is run (or shouldn't be run) and what pitfalls may befall us if we go down a similar path. But understand that you're reading one account (whether by one person or one team of people). They have the vantage point of someone deep in the conflict. You're looking at their recollections of tactics, not the overall strategy brought them to the place.
+
+## Ranking programmers
+
+There are many metrics for which folks rank various programmers. You've likely seen these metrics manifest themselves in competition sites, commits to projects, productivity, turn-around of code, and good ol' gut feelings. We do it to ourselves and others. We compare our work against our peers and folks that we admire. But that can lead us to make comparisons that aren't objective or based on all of the data. I can compare myself against folks who do low-level programming and find that I don't measure up in that realm; never mind that I haven't done a whole lot of low-level programming. Or I can compare myself against folks who were mentored by programmers whose names are legendary in the field. Unfortunately I will likely find gaps between my knowledge and their knowledge. Comparisons like this tend to be unhelpful and lead us into punishing ourselves for not being the other person. We look at our projects and our history and find that we're not the other person, nor could we ever be the other person.
+
+The major problem with ranking programmers (or really anything for that matter) is that ranking systems are based on one set of criteria. There is no real standard for ranking programmers. Sites that rank programmers based on the number of problems they've solved have only determined that there are a set of programmers who really enjoy solving these sorts of problems and will spend the time to do so. It tells us little about the programmer's abilities. Or we can look at how many lines of code a programmer used in order to solve a problem, or how "clean" the solution is (clean being another nebulous term). We can look at the Big O notation of the code that a programmer generates or how well the code adapts to various circumstances. Very little of this tells us anything about the programmer themselves. What it does tell us is that the programmer has had experiences that lead them to that particular solution. It tells us that the programmer has seen these sorts of problems before and has thought deeply about how to make them better. We learn that the programmer has devoted time and energy to practice these sorts of problems. What it doesn't tell us is an overall measurement of the programmer's skills or abilities. It's similar to the apocryphal tale of a brilliant professor. This professor was an absolute genius in his field and was one of the go-to people for answers about his subject. But despite his brilliance he was unable to understand how to change a tire on a car. Does that mean the professor was not as brilliant as folks claimed him to be? Hardly. It just meant that the professor had spent more time in his profession than he had changing tires. The same is true for programmers. If a programmer spends most of their time solving a particular set of problems they will eventually become skilled at those sorts of problems. But if they struggle with a different sort of problem it doesn't discount their overall skills; it just points out an area that they might want to work on.
+
+## Measuring programmer output
+
+There's also a tendency to measure programmer productivity via how many commits the programmer can make to a project. In an era of social coding sites like Github / Gitlab we can easily look at what other coders are committing and feel that we're somehow not measuring up. And unlike certain measurements of old (lines of code, which measures how many lines of code a programmer adds to a program) we can see the quality of their commits to a project. It can be daunting seeing a lot of quality work done by our peers.
+
+This too can be a source of frustration and feelings of inadequacy. "Why can't I be as productive or useful as this other person" we might say to ourselves? Or worse, these metrics may be used by others to judge productivity and we may find ourselves being criticized for our output (or lack thereof).
+
+Unfortunately commits and lines of code are the most visible measurement of coding productivity, but they don't show much about the actual practice of programming. We can't measure to any degree of accuracy the amount of time thinking about the problem. We don't see the mounds of reference material the programmer used in order to figure out a solution. And we certainly don't know just from looking at commits if this is the result of one person's afternoon of work or many days of work (unless they commit more often). We might find that this person is committing the work of multiple folks in their organization with the committer as the focal point for the other contributions.
+
+Measuring ourselves on the quantity of others output is easy and seductive but it isn't useful for figuring out how to improve ourselves in relation to the other programmer (other than "generate more commits". That line of thinking can lea us to thinking that we're not spending enough time doing "actual programming" and lead to overwork, stress, and burn-out.
+
+## Traveling Companions
+
+There can be times when it is useful to compare ourselves with other coders. Sometimes we can learn about new technologies or new methodologies by looking at the work of others. But it's very easy to fall into the trap of thinking that because we're not at the level of other coders that we're somehow inferior to them. Rather than looking at other coders as competition we should look at them as companions. We're all in this profession working to make our respective projects better. With Open Source / Free Software we have a unique opportunity to be able to look at how other folks do their work in public. We can learn from the code of others much in the same way that scientists can look at the papers of other scientists to see what worked (by replication and repetition). No coder is completely isolated from the work of others. Rare is the programmer that achieved everything they achieved without looking at the work of others to help their own coding efforts. We all learn from each other. But rather than be intimidated by the work of others we can instead take it apart and learn from it. And if we're lucky we can have the opportunity to ask others about how the code works and why they chose to do it that way.
+
+There's value in being able to ask questions of our fellow coders. We tend to overlook asking questions for feeling like we're going to ask something obvious or ask a question that will make us feel inadequate for asking. Asking questions is very useful when we don't understand what is going on with a particular piece of code. There are coders out there tho don't mind answering questions, and my hope is that you find them. Granted there are some who are very busy; who might not have the time to answer our questions in a manner that is useful to us. But if we are truly stuck and have exhausted all other avenues perhaps we can ask questions of them that don't require much of their time and effort and we can both be happy for the interaction.
+
+There is an art to asking questions and it can be frustrating when folks don't answer our questions, or come back with other questions / suggestions that are less than helpful. This can manifest itself in exchanges where person A asks: "I'd like to know how to do X" and persons B and C respond "I would do Y instead". It's easy to be angry at those folks and think "they're not answering my question!". It's also easy to get embroiled in exchanges with folks about the merits of doing Y where clearly I had inteneded to do X all along, thank you very much. But if we re-frame the experience as "this person is trying to help me; perhaps there is something in this recommendation that might be helpful." then we can have a better conversation.
+
+Of course there are folks who don't respond with your best interests at heart and are only interested in pushing their own world-view upon you. And it can take a lot of energy to engage with these folks to tell them "no, I really, really intended to learn more about X". I don't have good answers for how to handle these folks outside of thanking them for their time and finding someone else to ask. But this is also part of our growth process.
+
+If we look at other coders as our traveling companions on this journey; as peers in our coding practice, then we can realize that we're all in this together. Even if someone has many more years of experience than you they are your peer. You have knowledge and experience they don't have, and they have experience and knowledge you don't have. If we strip away the barriers of ranking and meritocracy we can better engage with each other and learn from each other.
+
+The journey to becoming a better programmer is long and hard. We need the best companions we can find to help us along the way. And not just the technically-skilled companions but the companions that we can talk to when the day is done and commiserate about our struggles together.
--- /dev/null
+# The mistakes along the way
+
+Discuss making mistakes, how to best make mistakes, and the best ways to learn from those mistakes
--- /dev/null
+# The inns we stayed at
+
+Discuss the different communities and how there's something to be learned from programming in languages that aren't considered good languages. Discuss how there's no such thing as a truly bad language.
--- /dev/null
+# A day's journey
+
+Discuss productivity for developers and how programming can be exhausting. Discuss the myth of always being on as a developer and the need for downtime and rest.
--- /dev/null
+# The map is not the territory
+
+Discuss the ever-changing facets of programming and how keeping current with it all is both a challenge and a myth
--- /dev/null
+# The tales at the inn
+
+Discuss how this is a continuing journey and how every day is another link in our journey.
--- /dev/null
+The Mediocre Programmer
+
+Copyright (c) 2018 by Craig Maloney
+
+Released under a Creative Commons CC-BY-SA International 4.0 license.
--- /dev/null
+# The Mediocre Programmer
+
+## Introduction
+
+Let's face it; we don't want to be mediocre programmers. We want to be great programmers; superlative programmers. We want to be the programmers they call whenever they're in a bind and we want to be the programmers that rush into the code base and produce perfect code in a matter of minutes. Code that would sit in the Louvre as a work of art, studied by generations of programmers for its intrinsic beauty and exceptional functionality.
+
+Why would we want to be mediocre programmers? Mediocre is the opposite of great. Shouldn't we strive to be great programmers?
+
+Sure, we should strive to be great programmers in the long term. But to become great programmers we have to pass through being mediocre programmers first.
+
+Mediocre programmers know that they're not great yet. Mediocre programmers see the distance between where they are and where they want to go in their programming career. They see the work that goes into a being a great programmer and they know that one day they'd like to be that great programmer.
+
+But they also see their own faults and failings. They see their browser history littered with online-searches for basic syntax and concepts. They see their email archives of questions they've asked other developers. They look at their code from several months back and wonder if they'll ever get to be great programmers with all of those mistakes and missteps. They see the gap between them and the great developer they wish to be and it feels like that gap widens every step of the way.
+
+The mediocre developer wonders if it's even worth it; if they should do something else with their lives other then computer programming. Maybe they're not as good as they thought they were, or maybe they lack that special talent that great developers have. Maybe they learned the wrong things early on in their journey, or maybe they think they should have started sooner.
+
+They see others being wildly successful and wonder if they were absent the day that the good programming genes were handed out.
+
+The truth is we're all mediocre developers in some way. We all still ask questions and have to look up syntax and concepts in our day-to-day programming. Computers continue to add complexity to everyday programming tasks and it takes a lot of mental bandwidth to keep all of those concepts fresh in our mind.
+
+## Why this book?
+
+This book is about helping you along on the journey of being a mediocre developer. Together we'll uncover some of common misconceptions we have about programming, failure, and growth and come to understand that the act of programming and development is something we undertake each day and improve in small ways. It's these small changes that over time transform us from being mediocre developers into better developers.
+
+There are plenty of books on how to become a better developer out there. Usually they have checklists and other things that the author deems important for you to do in order to become a better developer. This book will try not to saddle you with more work (you likely have enough as it is). Rather, we'll discuss what it feels like to be a programmer. We'll talk about the emotion of being a programmer; the feelings of frustration, guilt, anger, and inadequacy. We'll talk about those feelings you have of giving up and walking away from computing and whether those feelings come from a place of love or a worry that you're not keeping up.
+
+This book is a personal journey for both of us. It's a memoir of my time as a programmer and my feelings along the way. I've thought many times about giving up and finding a different career path but doing anything other than being a computer programmer scares me even more. Does that mean I'm stuck in a perverse ouroboros of self-pity and self-doubt? Hardly. It means that I need to dig deeper to understand why I chose the path of being a programmer and realize that it took a lot to get here and it's going to take a lot more to get where I want to be. It's a commitment to seeing things as they are now and moving forward from wherever I'm standing.
+
+Let's start the journey with figuring out what lead us here and where we are now.
--- /dev/null
+<dc:rights>Copyright 2018, Craig Maloney. Released under a CC-BY-SA International 4.0 License</dc:rights>
+<dc:language>en-US</dc:language>
--- /dev/null
+---
+title: 'The Mediocre Programmer'
+author:
+ - Craig Maloney
+tags: [developer, programmer, mediocre]
--- /dev/null
+% The Mediocre Programmer
+% Craig Maloney
+% Released under the CC-BY-SA International 4.0 license
--- /dev/null
+# The Mediocre Programmer
+
+
+A handbook for growing the programmer within.
+A love-letter to an industry and those struggling to make a go of it.
projects / themediocreprogrammer.git / commitdiff
