My last Pluralsight course for this year is out!
I started out this year with the goal of creating 30 Pluralsight courses, this Beginning Lua course represents the completion of that goal.
It definitely feels great to accomplish what I had planned, even though the process may have been a bit painful at times. This is definitely the biggest single undertaking I’ve ever accomplished in my career.
Here is the official course description:
Lua is an extremely versatile and popular programming language that you’ll find embedded in many other applications like Adobe’s Lightroom or even World of Warcraft. Many developers are surprised to find that even very popular games like Angry Birds are written in Lua.
In this course, you’ll learn how to quickly get started writing programs and scripts with Lua. I’ll take you through the basics of Lua, show you some tricks that demonstrate the Lua’s flexibility and even show you how to use Lua in an object oriented way.
We’ll start off in this course by learning a bit about Lua itself and Lua’s history, as well as learn how to download Lua and use the popular SciTE IDE for creating and running Lua code.
After we are setup and ready to develop some Lua code, we’ll learn the basics of Lua as we jump right in and build our first application. We’ll go over Lua’s type system and learn how to assign variables, utilize operators, use conditional logic and create loops.
Once we’ve got the basics covered, we’ll explore two powerful concepts in Lua: functions and tables. We’ll learn how functions work in Lua and what makes them so powerful, and we’ll see how tables can be used for more than just storing simple data.
Even though Lua itself doesn’t have a class construct, we’ll learn how to do object oriented programming in Lua using tables and metatables.
Finally, we’ll wrap up the course by learning a little bit about the standard libraries that come with Lua. I’ll show you some examples of using some of the most useful functions in the standard libraries and show you where you can get more information about them.
I often get asked by beginner programmers what programming language they should learn.
This, of course, is a tough question to answer. There are so many different programming languages today that a new developer, or even a seasoned developer, wishing to retool his or her career, could learn.
I’ve actually tried to answer this question before in a YouTube video, but I want to revise and refine my answer a bit here, because some of my views have changed and I’d like to give a bit more detail as well.
The wrong question to begin with
It turns out that what programming language you choose to learn is not actually all that important
Things have changed quite a bit from back when I first started my career in software development. Back when I first started out, there were much fewer choices of programming languages and there were much fewer resources available for reference. As a result, the choice was much more important.
For example, I started out learning C and then C++. At that time, it took quite a bit of work to master the language itself and to understand all of the standard libraries that were available. A good C or C++ programmer back then had a very in-depth understanding of every nook and cranny of the language and they needed this knowledge, because of two main reasons.
- References were not as widely available, so figuring out a syntax or library available involved flipping through a huge book, rather than just typing some keywords into Google.
- Programming, in general, was done at a much lower level. There were far fewer libraries available to be able to work at higher levels, so we spent more time working with the language itself and less time working with APIs.
Contrast that with the programming environment of today, where not only is information widely available and can be accessed with ease, but also there are a large number of programming languages that we effectively use to program at a much higher level due to the vast amount of libraries and reusable components available to us today.
In today’s programming environment, you tend to not need to dive as deeply into a language to be effective with it. Sure, you can still become an expert in a particular programming language, and it is good to have some amount of depth in at least one language, but you can literally learn a new language in less than a week and be effective with it almost immediately.
Now, before your alarm bells go off and you write me off as crazy, let me explain that last sentence in a bit more detail.
What do you mean you can learn a programming language in a week?
What I mean by this is that once you understand the basic programming constructs available in just about all programming languages, things like conditionals, loops and how to use variables and methods, you can take that same knowledge to a different programming language and just learn how to do those same things in that language’s syntax. In fact, most IDEs today will even help you with the syntax part, making your job even easier.
If you are already fluent in multiple programming languages, you probably agree with what I am saying, but if you have only ever learned one programming language or none at all and are looking to learn your first programming language, you might be a little skeptical. But, take it from someone who has learned and taught programming languages which I have learned in a week, the basics are pretty much the same.
Check out this book which basically deals with this exact subject, Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages.
Now, if you are just starting out, it is pretty unlikely you’ll be able to learn a whole programming language in a week. This brings us to the question, you may be asking yourself…
So, what programming language should I learn then?
Hold up. I’m still not quite going to answer that question. Because, it still isn’t quite the right question.
Instead of getting hung up on what programming language you want to learn, you should instead ponder what you want to do.
Learning by doing is the most effective way to learn, especially if you are doing something you have an interest in or is fun to you.
So, I always start new want-to-be developer out by asking them what they want to build.
Do you want to build an Android application? How about an iOS application? A web page? A game?
First, figure out the answer to this question and then let that answer guide you to choose the technology and programming language you will use to achieve that goal.
Don’t worry so much about which programming language or technology is most valuable. You can’t make a wrong decision and regret it later, because it won’t take you much time to retool later if you need to. Once you have the basics down and have actually used a programming language to build something, you’ll find that doing it again will be much easier.
I like to encourage new developers to write a mobile application—especially an Android application.
Here are some reasons why:
- A complete Android application can be built by a single person. Creating a complete application will really help you to feel confident about software development and is one of the best ways to really learn to code. I spent a good deal of my early career only being able to create bits and pieces of things, and it was frustrating, because I never knew if I could really “code.”
- By learning Android, you learn Java and how to use libraries and APIs. This will give you a good programming language to start with and you’ll get some valuable experience with APIs.
- Google gives you some free help and makes things pretty easy to learn. Since Google really wants you to create Android applications, they have put quite a bit of work into creating easy to use tools and tutorials to help you be successful quickly. (I’ve also created some tutorials, which you can watch at Pluralsight here as well.)
- You can actually make money while learning and teach yourself a very valuable and upcoming skillset. Not only can you sell your Android application or monetize it in some other way, but you will be learning a complete set of software development skills for a platform that is in very high demand.
Aha! So Java it is then?
No, not exactly.
Summing it up
I’m actually working on some products to help developers manage their careers and lives better which will cover topics like this one a bit more in-depth. If you are interested in receiving some updates when I publish an interesting article or video, or when I launch some of those products, feel free to sign up here. Don’t worry, I won’t spam you. J
Update: be sure to check out this comment chain to see a bit more clarification on what code katas really are. Thanks for Cory Foy for pointing out that I was unfairly calling all code katas as solving the same programming problem over and over again. Only some people treat code katas that way and this post is about why that kind of code kata is not effective. I also updated a few words in this post to reflect this point.
I don’t want to seem like I am bragging, but there is something I just have to get off my chest.
But, before I tell you what amazing skill I have mastered through countless hours of boring practice, let me tell you a bit about my training schedule.
Everyday I get up in the morning. I put on my shoes. I begin my practice.
Usually I start with a small warm-up, just to get the blood flowing on the way to my office at the end of the hall.
Later in the day, I’ll wander out of my office for lunch and practice more on the way to the kitchen.
Right now as I am typing out this blog post, I am on the treadmill honing my craft one painstaking repetitive step at a time.
That is right, you may have guessed it by now—I am a master walker.
All my life I have been practicing this humble skill. Each and every day I practice my secret craft. I see other fools riding around on mopeds and motorized scooters sheepishly talking of their perceived skill at bipedal transportation. But, although outwardly I acknowledge their words, inwardly I know that I am special, because I hone my skill to a craft.
Sounds ludicrous? That is what it sounds like to me when some people talk about doing code katas.
What is a Code Kata you may ask? Some people think a Code Kata is when you solve the same programming problem over and over again, thinking you are actually practicing something other than using shortcuts in your IDE. (To be fair, not all people view Code Katas that way.)
These kinds of Code Katas come from a failed attempt to forcibly simulate the same kind of practicing that a musician or athlete would perform in order to become better at their vocation.
Why Code Katas aren’t effective
Don’t get me wrong, the intention behind Code Katas seems to be well placed, and I am all for software craftsmanship (although not the elitism that sometimes accompanies it.) But, just as walking every single day doesn’t make you a master walker, and driving a car every day doesn’t make you a superior driver, solving the same sets of programming problems over and over again won’t make you a master programmer.
If you still have your doubts, consider old people. Old people are not master walkers or master drivers, yet they have been doing both of those activities day in and day out for many years. Not only do they not master these skills, the skills actually atrophy—they become worse at them, and not just because their muscles and reflexes become worse from age, it is because repeating the same thing over and over again without an increasing level of challenge actually results in the mind becoming complacent with the activity which leads to the eventual degradation of it. (At least, this appears to be the case to me.)
Don’t lose hope though, a little later on I will tell you a real way to practice your craft in software development—one that will give you results—but, first let’s dissect the cases of walking and driving a little bit further to see why repeated practice of those activities seems to have diminishing returns.
Doing the same thing over and over again doesn’t make us better at it
We first learn from walking and driving, because everything is new and challenging. Although walking seems like a repetitive process, it is actually the lack of repetition that provides the challenge our brain and body need to actually benefit from it.
As a toddler learning to walk or a teenager learning to drive, we are constantly bombarded with new scenarios and challenges that we haven’t faced before. What happens when the dog runs by and brushes our leg? How does this affect our balance and what do we have to do to adjust? What about this new surface? The carpet seems to absorb our feet and create more friction when we attempt to walk on it. How do we compensate to balance on this surface? Walking with socks on the floor gives us less grip, etc.
But, as an adult, or experienced walker or driver, we are not challenged in nearly the same way; we’ve already seen most of the scenarios. Our daily commute to work rarely presents us with an unfamiliar stimulus or problem to solve. We operate on autopilot, automatically walking and driving to our destinations without much effort or thought.
Repeatedly writing the code to solve the same programming problem over and over again is exactly the same thing, except unless you are introducing new challenges by adding constraints and twists, you are only benefiting from the exercise the first, and perhaps, the second time, you undertake the activity.
Now, not all programmers who do Code Katas repeat the exact same code over and over again. Some of them attempt to solve the same problem, but this time not using any loops or limited the line count to a certain number or some other similar constraint. This kind of practice is actual worthwhile practice which challenges the mind and introduces new scenarios that create new neural pathways in the brain and strengthen others. (Here is a great example of book that encourages you to do just that. I highly recommend working through the problems in this book.)
Simply typing the same code into the same IDE over and over again for 10 minutes a day may make you feel relaxed and calm or even like a concert violinist arduously practicing their scales, but at the very best it will make you faster at using your IDE and typing code; skills which can be easily practiced through the course of a normal day’s work. If you want to be really good at writing the code to sort lists of words and calculate prices for grocery store items in a cart, go ahead, be my guest.
How real mastery is achieved
If you are resisting what I am saying at this point, it is likely because you still mistakenly believe that walking and driving are in a different category than playing music, sports and programming. But, the truth of the matter is that walking, running, music, sports, and programming are in the same category, or rather, there are no categories.
It turns out there are actually master walker and master drivers. One sport that is not all that widely known goes by the name of Parkour or Freerunning. Don’t believe me, check out this video for an example. In this sport, the athlete becomes exceptionally good at traversing around everyday locations on their own two feet. It is amazing what some of these practitioners can do—just watch the video if you don’t believe me.
And as for driving, I probably don’t need to convince you that Nascar is “kind of a big deal.”
My point is that you are not going to become a Parkour expert or Nascar driver by just walking around your neighborhood or driving your car to and from work, even if you do tend to drive like a bat out of hell. To get to that level of skill in those seemingly mundane activities, you have to constantly practice at a higher level of difficulty and continually introduce new challenges.
In fact, when we actually look at what real musicians and sports athletes do, it is much of the same. I seriously doubt many musicians you hear on the radio or see in concert repeatedly played “bah bah black sheep” or “twinkle twinkle little star” on their instruments until one day they achieved mastery. And in the professional sports world, achievement only comes through repeatedly pushing beyond one’s limits day after day.
The point is this: if you want to get better at something, repeating practice alone is not enough. You must practice with increased difficulty and challenge.
How to improve your programming skills
So, how then do you become a master craftsman at the vocation of software development? If you don’t use Code Katas, how do you practice your craft?
Let me start off by giving you the best example I have ever seen.
This is Jennifer Dewalt’s blog; she decided to learn to code by building 180 websites in 180 days. While you are sitting at your keyboard typing the same 20 lines of code into your IDE over and over again, Jennifer is creating a new thing every single day and facing a brand new challenge.
Who do you think will improve their skills more after 180 days, you or Jennifer? I know who I’d hire without even thinking twice.
I get lots of emails asking me about the best way to learn programming or how someone can improve their skills. Recently, I’ve gotten a lot of emails asking about how to learn Android development. Do you know what I tell all these inquisitive minds?
Make Android apps.
But, umm, what book can I read?
No book, just come up with an idea and try to create it. Figure out what you need to do along the way. When you get stuck, go look for the answer or seek help.
But, I need to know what I am doing first.
Says who? Do and then learn. Learn and do at the same time, reading a book or repeating the same exercise over and over again won’t make you smarter or more skillful; constantly challenging your mind and current skills will.
Want to learn more?
I’ve got plenty more to say on the topic and many more techniques that are way more effective then Code Katas which you can use to hone your programming skills. I can’t fit it into a single post like this, but I’ll be putting it into the top secret project I am working on to help developers boost their careers and learn to market themselves.
If you’d like to be one of the first to be notified when it is available, sign up here. I’ll be including lots of practical valuable information that you probably won’t find anywhere else.
So, what do you think? Do you do Code Katas right now? If so, do you think they are actually useful? Let me know in the comments below.
My software development career began about 15 years ago.
But only in about the last 5 years did I really start to see a large boost in my software development career.
Here are some of the things I wish I would have known when I got started in the software development industry; things that would have made me more successful, much earlier, if I would have known them.
There is no “right way” in software development
I wasted a large amount of time, both in studying and arguing, early on in my career, falsely believing there was an absolute “right way” for many aspects of software development.
It turns out that just about everything I once thought was correct about software development at some point turned out to be wrong.
But more importantly, I found that very few things were black and white. Almost every decision when writing code and developing software is based on the current circumstances.
I’ve talked before about how the religious adoption of a technology can be harmful to software developers, but this topic goes beyond just a technology.
It is also true that no best practice is universal. Even highly charged topics like whether or not to unit test or whether agile or waterfall methodologies are best, do not have straightforward one-is-always-right answers.
In my career, I’ve wasted plenty of time on the “right way” road that led to nowhere instead of taking the “pragmatic” (practical) road, which would have carried me much further.
Reading a book cover-to-cover is not the best way to learn
When I first started wanting to grow my knowledge of programming and different technologies, I spent too much time reading technical books about a specific technology cover to cover.
There is nothing wrong with reading books, but often the choice of what book to read and what parts of it to read are very important.
For example, I remember reading a very large book on programming with Visual C++. (I’m pretty sure it was an earlier version of this book.) Anyway, the book was a good book with lots of information, but reading it cover to cover was not the best approach to learning Visual C++.
I would have learned and retained a lot more by skimming over the chapters of the book to get a broad understanding of what there was to know about Visual C++, then figuring out what things were most important to learn first.
I would have had much more success by sitting down and actually practicing the basics by trying to actually build something than just reading or going through examples in the book. You don’t really learn a technology until you’ve solved real problems with it.
Learning particular technologies in-depth is a waste of time
Not only did I waste time by reading books cover to cover, but I also often chose to read the wrong books.
I had mistakenly believed that learning a particular technology inside-out would be a good way to advance my career.
I spent too much time reading books about very specific technologies like ASP.NET or Hibernate instead of reading more books like “Code Complete,” “Clean Code,” and “Agile Principles, Patterns And Practices in C#.” (All of these books, by the way, I recommend that you read, if you haven’t already.)
While it is important to know about the technology you are using, it isn’t important to be an absolute expert in that particular technology. There isn’t much benefit to knowing the exact API call to make when you can just easily look it up when you need it.
Too many technologies that I spent a good amount of time learning about in depth, ended up either dying out or being technologies that I eventually abandoned myself. Most of the knowledge about those specific technologies ended up representing a big waste of time.
I found that it was important to become an expert at whatever programming language that I was using at the time, because expertise in a particular programming language will usually last you a pretty long time; I definitely would have still spent time learning in depth about C++, C# and Java, but, I perhaps, spent a little too much time learning all the intricacies of C++, which isn’t benefiting me much now.
Community is extremely important in your software development career
I was always good about helping my coworkers and being social at the various jobs I held, but I never really reached much beyond my company.
I spent a large amount of time trying to make an investment in my career at a particular company at the expense of making an investment of my time in the software development communities that I was involved in.
I spent lots of time creating internal presentations on technologies or best practices that could have been spent creating content and material that could have served the community as a whole, as well as brought me recognition at my job.
I also made the mistake of not thinking that I had something valuable to contribute.
I talk to many beginning software developers now and sometimes I think they have much more to contribute to the community than us software developers that have been in the field for a long time, because they understand better the issues that other beginners are struggling with.
If I could do it over again, I would have made sure to be much more involved in conferences and user groups earlier in my career. I would have started my blog much earlier and I would have used much of my learning time to create projects and resources that would be able to help others rather than just reading a book.
Always have a side project
Perhaps the biggest change I would have made that would have impacted my career the most would have been to cut out all the TV watching, Everquest and World of Warcraft playing I did earlier in my life and replace that time with work on a side project.
I’ve wasted a pretty sizable amount of time in my life doing things that were enjoyable, but didn’t produce any long term benefit for my life.
About 3-4 years ago, I pretty much cut out watching TV completely and now I hardly ever watch movies either. TV and most movies are just a huge waste of time that you could be using to do something useful. The same goes for video games for the most part, but at least with video games you are actively doing something not just absorbing useless information.
I’ll always love to play video games and I don’t think I’ll ever stop, but I do wish I would have spent a good deal of the time I spent playing video games and watching TV on a side project instead.
Sadly, the first real side project I actually took on was only about 3 years ago when I started creating my first Android application.
When you are working for someone else, it is really important to spend time working for yourself as well, otherwise you are building someone else’s empire while neglecting your own.
Not only did I learn a huge amount from the side projects I have taken on in the last few years, but I have benefited greatly from them. In fact, one of those side projects, creating Pluralsight courses, is something I am doing pretty much full time now.
Putting everything I learned together
These are just a few of the things that I wish I had known when I first started my software development career, but there are many more and lots of other things that I did do right from the beginning.
I’m actually working on a top secret project to put all this information together to help developers boost their career and learn to market themselves.
If you want to be the first to be notified when this project gets officially launched, sign up here, and I’ll be sure to let you know.
What about you?
What are some of the things you wish you would have known when you started your software development career? Let me know in the comments below.
Computer science itself is a surprisingly difficult thing to define.
If you do a search on the web you’ll turn up quite a few definitions for computer science.
Some people take a very academic approach and say that computer science is about studying computation and systems of computation. (What the heck does this mean?)
Other people will define it in terms of what they believe it is about, saying things like computer science is using computers to solve problems.
None of these definitions or attempts at defining computer science sit well with me.
Why it is important to know what computer science is?
So, you might be thinking “who cares?” “What does it matter what computer science is?”
Well, the reason why it matters is because many of us programmers and software developers either have a degree in computer science, are studying to get a degree in computer science, or simply associate our knowledge with the field of computer science.
It seems kind of silly to have a degree in something that you can’t clearly define nor can anyone else.
Have you ever thought about how strange it is that when someone gets a degree in biology they become a biologist, but when someone gets a degree in computer science they become a senior software engineer?
Why is computer science so hard to define?
Before we can even really attempt to define what computer science is, we have to understand a bit about why it is so hard to define.
It all stems from the problem that unlike many other sciences, computer science isn’t based on any naturally occurring phenomenon. Even social sciences and formal sciences deal with things that exist in the world without our creating them.
But, computers are a creation of humans. At least the kind of computers that we commonly recognize as computers and use in the field of computer science.
Everything within the idea of computer and computation is completely fluid and lacks perfect definition including the idea of a computer itself.
We can’t even define computers
I spent several weeks researching what a computer is and I found there is no commonly accepted definition of a computer. It wasn’t even till around 1940 that the definition of computer transferred from the term for someone operating a computing machine to the actual machine itself.
No, that is not a typo and I’m not off my rocker. It is a true statement. Consider whatever computer you are using to read these very words; are you actually running your software directly on the hardware?
Most likely you have some sort of operating system which is running on your hardware that is virtualizing the actual physical hardware to a large degree. Most applications are written to run on an operating system, not to run on actual hardware. This, in effect makes the operating system the computer.
We can take it one more level and say that the very web browser you are using to view this post, is itself a computer, since a browser can be programmed to run just about any application (That is to say that a browser is Turing Complete).
Data and code
Even the text content of this blog post, which most people would say is data, is actually code, because it is programming the web crawlers from search engines like Google and telling them what to do based on the actual content of the words. You may have even found this post due to my attempts to program Google’s web crawler through SEO techniques.
Everything about a computer is fluid and abstract
All of this leads up to the realization that just about everything in the computer world is defined in terms of abstractions which are always “leaky.” Other branches of science like mathematics and chemistry are much less abstract and based on real concrete things that exist in reality.
What then is computer science?
Ok, so now is the part where you probably expect that I will tell you what exactly computer science is, right? Wrong.
Computer science is nothing. It isn’t a thing that can be defined, because it is not a thing that exists beyond our imaginations.
Computer science itself is an abstraction that we have created for dealing with all the things involved with computers which is itself and abstraction for all kinds of programmable machines.
It is a false science. Everything you might study in a computer science program actually belongs in some other field of science, but is conveniently grouped into the computer science abstraction in order to catalogue the important things that form the basis of how we build computers and how we program them.
This isn’t to say that the things you would learn in a computer science program don’t have value. It is important to know about algorithms, data structures, computer architecture and the mathematics that many of these things are based on, but it is important to realize that the study of computer science is very different than the study of other fields, because most of the concepts you learn about in a computer science program are abstractions. They are not rules that are set in stone, like the forces of nature that form the basis of other fields of study.
I say this because it is important to understand that everything we learn about computers is based on abstractions we have created to simplify the complex and these abstractions are based on very few actual rules that can’t be broken.
We will eventually hit a point where many of these existing abstractions about computers that we have put into place and built our knowledge upon, will have to be broken and replaced with new abstractions.
I’ve just published a new Pluralsight course, Introduction to Hibernate.
This course was definitely a difficult one to produce. There is so much to cover in Hibernate, and there was no way I could cover it all.
Here is the course description:
In the world of Java one of the most popular and widely used frameworks is Hibernate.
Hibernate is an ORM or Object Relational Mapper that allows developers to map Java objects to relational database tables. It is a valuable tool that all Java developers should know how to use.The problem is, learning Hibernate can be difficult. Hibernate is a very large framework and there are many important concepts to understand to use it effectively.
Are you a developer who…
- has been wanting to learn how to use Hibernate
- struggles to use the application
- has never really understood Hibernate
This course is designed to give you the knowledge you need to feel confident about how Hibernate works and how to use it.
What this course offers:
This course is designed to make getting started with Hibernate as easy as possible and focus on the most important things you need to know. John starts off this course by teaching you a bit about Hibernate and how it works.
Then you will see how to get it setup with a real MySQL database installation. After that you will learn the very basics of mapping, which is one of the most important things to understand about Hibernate.
John will show you how to create a basic mapping for a Java object to a relational table and explain to you how the mapping works. He also covers some of the complex mapping situations like mapping collections and different relational mappings like one-to-many and many-to-one.
Once you’ve learned how to map you objects, you’ll want to know how to query them, so he’ll show you how to do this using Hibernate’s built-in HQL and using a more object-oriented approach with the Criteria API.
Finally, he wraps things up by taking a brief tour of some of the more advanced features like caching and interceptors.
Don’t stick your Weiner out there
It’s good to get noticed, but make sure you get noticed for the right things. You don’t want to be caught with a permanent picture out there on the internet of the things of yours that should remain hidden.
What I mean by this, is that as a software developer you want to look like a software developer, not a political activist. I’ve said this a lot of times in various forms, but with the recent huge media coverage of a certain trial in Florida, I’ve seen way too many software developers potentially ruining their careers because they were so eager to show everyone their—opinions.
Remember, the internet is a permanent record that can never be erased. No matter what you do, some server out there somewhere will have a record of what you posted, or someone will have taken a screen capture of it.
The same goes for the workplace in general.
People get really offended when they think I am giving them the message to not be themselves. When I say things like this, I hear many developers retort, “What? If an employer or customer doesn’t like who I am, then I don’t want to work with them either.”
I’m not saying don’t be yourself. I am saying show the best version of yourself possible. Everyone in the world appreciates discretion and tactfulness. Few people want to work with someone professionally who publically ascribes to themselves the opposite characteristics.
Your Weiner isn’t too big to fall
Just because you have done great things in the past doesn’t mean you will get credit for them in the future. As a software developer you are constantly evaluated based on the skills you possess now that are valuable in the current market, not the ones you had 5 years ago that were valuable in that market.
I see many software developers that were once great legends who accomplished splendid things in the past resting on their laurels.
You chose this industry, no one else made the choice for you. So you should have known going in that software development was a industry constantly full of change and flux.
If you want to learn some set of skills that will last your whole career and never require you to change or learn something new, perhaps you should be a plumber or an electrician. (Although, I’d venture to guess even those positions would have some degree of continual learning involved.)
The point is, knowing C++ or COBOL or assembly language is only going to take you so far for so long. If you want to keep rising up and not fall backwards in your career, you are going to have to be that old dog that learns some new tricks.
No one wants to see your Weiner
You always have to remember that people primarily think about and are concerned with themselves.
When I hire someone to do a job, I don’t hire them because of how awesome they are, I hire them because I think about how awesome of a job they will be able to do for it.
I know many software developers who have tried to make their mark by showing how superior and awesome their own skills are, instead of demonstrating practically how they can be beneficial to a team or a project.
When hiring someone to pack and move your house would you rather hire a big muscly guy who stands around flexing in the mirror or would you rather hire a mediocre strength average Joe that is extremely hard working and diligent?
Yet, so many software developers I talk to try and show themselves as the big muscly mover, but make no indication of what kind of job they will do.
All the skills and ability in the world are of no good to anyone unless they are put to use.
Flashing your Weiner once can be forgiven, doing it twice gets you in trouble
It is OK to make mistakes, everyone makes mistakes. It is part of life and it is good. Failing is part of learning. However, when you make a mistake and you are called out on that mistake, you should carefully avoid to make the same mistake again.
I’ve seen quite a few people get fired—excuse me “laid off”—and the reason has almost always been for making the same mistake more than once.
When you are called out on a mistake you have made and you make that exact mistake again, especially within a short time frame, it is taken as an utter disrespect and contempt for authority and often as a sign of extreme arrogance and recklessness.
Of course this all hinges on the size of the mistake. It isn’t as big of a deal to forget to add the bug number to the comment of the check-in you made, a couple of times, but taking down production for a day will probably only be forgiven once.
Don’t be paranoid about making mistakes and failing—fear will paralyze and destroy your progress, much more than mistakes will—but, instead be cautious, careful and deliberate in your actions. If you make a mistake, learn from it. Take steps to make sure it won’t happen again and then move on.
More career advice and tips
If you like this article and want to get more useful software development career tips and advice, take a moment now and sign up to be notified when I launch my top secret product that will help developers give their career a huge boost.
Wow, I can’t believe I have actually reached the milestone of authoring 40 Pluralsight courses
My first Pluralsight course, Introduction to Android Development, was released on April 12th, 2011. That is just over two years ago.
And my latest course, which makes number 40, if you count my contribution to the Design Patterns course, is Using Glimpse With ASP.NET, MVC4, and Entity Framework, which was published on May 5th, 2013.
The total hours of video content I have published in the 2 years from my first to my latest course is around 122 hours. That means you could watch my Pluralsight courses for about 5 days straight.
But before I tell you about what I learned from this experience, I just want to take a moment to say thank you.
I couldn’t have done this by myself and I am very thankful to everyone that helped me reach this important milestone.
I have interacted with many of you over email and Twitter and I have gotten lots of positive feedback and encouragement as well as some constructive criticism which has greatly helped me to improve my courses and to feel like I am doing something that is meaningful and helpful to many people.
So, sincerely, from the bottom of my heart, I thank you faithful viewers for watching my courses and I commend you on being the kind of developer that cares about learning and improving their skills.
I also want to thank Pluralsight and all of the staff and management of Pluralsight. When I say that the folks at Pluralsight are some of the best people I have ever had the opportunity to work with, it is no lie. I have never met a more friendly group of energetic people that really care about what they do than the management and staff of Pluralsight.
The biggest lesson from creating Pluralsight courses
You may be expecting that the biggest lesson I have learned during my super-speed course creation at Pluralsight is how to learn technologies quickly, and although I have certainly learned a great deal about doing that, the biggest lesson I have learned is that we can accomplish what we put our minds to if we are willing to not let anything stand in the way.
I don’t have any special skills or talents, besides my ability to say “Hi, this is John Sonmez from Pluralsight.” I’m just a regular guy who works really hard and stays as focused as possible.
But, I didn’t always have the work ethic that I do today.
In order to do that, I had to drop many things in my life that I used to like to do, like watching TV or playing games, and focus on my opportunity.
And, yes, the opportunity to author courses at Pluralsight is an excellent opportunity, and I realize that not everyone has that opportunity. But, we all have opportunities that sometimes are hard to see. Opportunities that we need to seize and make the most of.
Many of these opportunities are once-in-a-lifetime, some of them come and go. I’ve had opportunities in the past that I have let go, or I didn’t put my heart into, but with Pluralsight it was different.
I won’t bore you with the story of working a full time job for almost two years and doing Pluralsight courses every single night and weekend. But, in order to seize this opportunity, I had to put in some hard work and be willing to make some sacrifices.
The reason why I mention this is because, if you are reading this post, you are probably the kind of programmer or IT professional who is already starting to seize an important opportunity to advance your career and skills. I just want to encourage you that you can do whatever you want to do. You can be as successful as your willingness to work hard and believe in yourself will allow.
I hope that more than learning about a technology or development language from my courses, that I could teach you something much more valuable—the power of believing in yourself and not letting anyone put limitations on you.
Some other lessons
It is really difficult to summarize everything that I have learned over the past 2 years and 40 courses, because there is just so much, but here is a list of some of my biggest takeaways from this whole process.
- Learning a technology effectively can be broken into 3 steps
- Create something simple with it
- Learn the breadth of the technology to understand what there is to know about it.
- Determine the most important high level topics to learn and only go into details when necessary, you can always fill in the details later
- Effective teaching is showing people something new in terms of what they already understand
- Have a goal, make a plan to get to it, and don’t deviate from it until it is accomplished
- If you fall off the horse get back on as soon as possible
- Encouragement feels better than criticism, but criticism if much more valuable
- Writing your thoughts out refines them and sands the jagged edges off of them
- Redoing work is much harder than doing it right the first time
- Nothing is the best. No technology, no programming language, no way of doing things
- No matter how much you know, everyone and everything has something to teach you, if you will only listen
- It is very easy to type “HellWorld” and not notice until you’ve finished recording 30 minutes of video
- The right caption can make any image funny
- The key to efficiency a repeatable process
- Videos with just slides are much hard than videos with demos
- A good microphone adjusted properly makes a huge difference in audio quality
- Quotas are proactive, metrics a reactive
Onward to 50
So what’s next on my agenda? Hitting 50 courses of course.
I’ll be working hard for the rest of this year to keep producing courses, since I still have a pretty big list of ideas, but after this year, I’ll probably be slowing down a bit, since I can’t keep up this ridiculous pace forever.
So thanks again for to everyone for all the support and encouragement, and to Pluralsight for this awesome opportunity.
My YouTube video for the week
Get Up and CODE
And here is the link to the latest Get Up and CODE episode, where Iris and I interview John Papa about fitness. You can also listen to it below.
The recent free courses from Pluralsight on teaching kids to program really got me thinking about this subject.
There seems to be a big backlash in development community against the idea that everyone should learn to program.
I’m not sure exactly where it is coming from, but I suspect it has something to do with egos and fear.
Even within the development community, there seems to be a distinction between “real programmers,” and “not real programmers,” based on language or technology choice.
I have to admit, I have been guilty of this type of thinking myself, because a very easy way to increase our own value is to decrease the value of others.
But what I have come to find is that not only is the distinction between “real programmers” and “not real programmers” a false dichotomy, but that the distinction between a programmer at all and a layperson, is also not quite as clear, or at least it shouldn’t be.
Not everyone should be a programmer
It’s true. Just like not everyone should be an accountant, or not everyone should be a writer, but I think we can all agree, that everyone should understand basic math and be able to write.
Learning how to program and doing it professionally are two distinct things and they should not be lumped together.
It it pretty hard to imagine a working world where no one except writers could write.
Imagine wanting to send an email to your boss, but you don’t know how to write, so you have to ask the company writer to do it for you.
That is what the world would be like if we insisted that only writers needed to learn how to write.
But perhaps you think I am just being silly, I mean the need to write is so prevalent in everyday situations, but the need to program isn’t.
But I challenge you to consider if whether it is actually true that the need to write is much more prevalent than the need to program, or because everyone knows how to write, the need for writing is just recognized more.
Imagine if everyone you interacted with on a daily basis knew how to write code. Imagine that, just like everyone has a word processor on their computer that they know how to use, there was an IDE that allowed them to write simple scripts.
Think about how that changes the world.
The first thought that comes to my mind in that world is that there would be APIs everywhere.
Every single program would have an easily accessible, scriptable API, because every user of that program would want to be able to automate it.
In time, the way we viewed the world would completely change, because just like products today are designed with the thought that users of those products can write, products of that time period would be designed with the assumption that users of those programs can program.
Suddenly everything becomes accessible, everything interfaces with everything else.
Doctors build their own simple tools based around their specific process by combining general purpose software from their equipment.
There is a Pinterest full of code snippets instead of pictures.
Every device and piece of software you interact with has an API you can use to automate it.
The point is that we can’t conceive what the world would look like if programming was as prevalent as writing, but such a world can and should exist.
Computers and technology are such a large part of everyone’s lives that it is becoming more and more valuable to be able to utilize this so common element.
It starts with kids
We have to stop thinking programming is hard and realize that it is one of the easier things we can teach kids to do.
If a person can grasp and use a complex language, such as English, that person can learn how to program.
Programming is much more simple than any spoken or written language.
But, we have to stop erecting these artificial barriers that make programming computers seem more difficult than algebra.
Is there really much difference between an algebraic variable and a variable in a programming language?
Isn’t most mathematics solved by learning an algorithm already? Why not at the same time, teach how to program that algorithm? Not only would it make the subject much more interesting, but it would build a valuable skill as well.
We spend a great deal of time educating kids with knowledge they will never use—basically filling their minds with trivia. But, how much more likely would they be to use the skills learning to program would give them?
What was hard yesterday is easy today
Calculus, geometry, probability, the structure of a living cell, electricity… What do they all have in common?
These concepts used to be advanced topics that only the most educated in society knew about or discussed, but now have become common knowledge that we teach children in school. Ok, well maybe not calculus, but it should be.
Over time, the concepts that only the brightest minds in a field could possibly understand are brought down to the masses and become common knowledge.
It is called “standing on the shoulders of giants,” and it is the only way our society advances as a whole.
Imagine if it was just as difficult for us to grasp the concepts we are taught in school as it was for the pioneers of that knowledge to obtain it… We wouldn’t ever advance as a whole.
But, fortunately, what is hard yesterday ends up being what is easy today.
The same will eventually happen with computer programming, the question is just how long do we need to wait?
It’s all about breaking down walls
I try to never say that something is hard, because the truth is that although there are some things in life that are hard, most things are easy if you have the right instruction.
It is natural for humans to want to think the knowledge or skills they have acquired is somehow special, so naturally we have a tendency to overemphasis the difficult in obtaining that knowledge or set of skills, but we’ve got to work through the fear of job security and egos and remove the veil of complexity from programming and make it simple.
The value we can bring by helping others to understand the knowledge we have is much greater than the value that using that knowledge alone provides.
I used to be very confident in my abilities as a software developer.
I used to be able to walk up to a group of software developers and tell them exactly what they were doing wrong and exactly what was the “right” way to do things.
I used to be sure of this myself.
It wasn’t even that long ago. Heck, when I look at the blog posts I wrote 3 years ago I have to slap myself upside my head in realization of just how stupid I was.
Not only was my writing bad, but some of my thoughts seem so immature and uneducated that it feels like a completely different person wrote them.
And I wrote those posts back when I knew it all.
The more I learn, the less I know
Lately I’ve been running into situations more and more often where I don’t have a good answer for problems.
I’ve found myself much more often giving 3 pieces of advice attached with pros and cons rather than giving a single absolute—like I would have done perhaps 3 years ago.
I’ve been finding as I have been learning more and more (the past 3 years have been an accelerated pace of growth for me,) that I am becoming less and less sure of what I know and more and more convinced that there is no such thing as a set of best practices.
I’ve even spent some time postulating on whether or not commonly held beliefs of best practices would be thrown completely out the window given a significant enough motivation to succeed.
My point is that the more doors I open, the more aware I become of the multitude of doors that exist.
It is not just the realization of what I don’t know, but also the realization of weakness of the foundation I am already standing on.
Taking it out of the meta-physical
Let’s drop down out of the philosophical discussion for a bit and talk about a real example.
Perhaps the biggest quandary I struggle with is whether or not to unit test or practice TDD and its variants.
The 3 years ago know-it-all version of me would tell you emphatically “yes, it is a best practice and you should definitely do it all the time.”
The more pragmatic version of me today says, in a much more uncertain tone, “perhaps.”
I don’t want to delve into the topic in this post since I am sure I could write volumes on my ponderings in this area, but I’ve come to a conclusion that it makes sense to write unit tests for code that has few or no dependencies and that it does not make sense to do so for other code.
From that I’ve also derived that I should strive to write code that separates algorithms from coordinators.
I still even feel today that my advice is not wholly sound. I am convinced it is a better approach than 100% TDD and units tests, or no TDD and unit tests, but I am not convinced there isn’t a deeper understanding and truth that supersedes my current thoughts on the matter.
As you can imagine this is quite frustrating and unsettling.
Silver bullets and best practices
What I am coming to realize more and more is that there are no silver bullets and more surprisingly there are not even any such things as best practices.
Now I’ve heard the adage of there being no silver bullets so many times that it makes me physically sick when I hear someone say it, because it is so cliché.
But, I’ve had a hard time swallowing the no best practices pill.
I feel like when I abandon this ship then I am sailing on my life raft in the middle of a vast ocean with no sails and no sense of what direction to go.
A corner-stone of my development career has been in the learning, applying and teaching of best practices. If these things don’t exist, have I just been pedaling snake oil and drinking it myself?
Best practices are simply concrete applications of abstract principles in software development that we cannot directly grasp or see clearly enough to absolutely identify.
Breaking this down a bit, what I am saying is that best practices are not the things themselves to seek, but through the pursuit of best practices we can arrive at a better understanding of the principles that actually are unchanging and absolute.
Best practices are optimal strategies for dealing with the problems of software development based on a particular context. That context is primarily defined by:
- Language and technology choice
- Meta-game (what other software developers and perceived best practices are generally in place and how software development is viewed and understood at a given time.)
- Individual skill and growth (what keeps me straight might slow you down; depends on where you are in your journey.)
There is a gentle balance between process and pragmatism.
When you decide to make your cuts without the cutting guide, it can make you go faster, but only if you know exactly what you are doing.
Where I am now
Every time I open my mouth I feel like I am spewing a bunch of bull crap.
I don’t trust half of what I say, because I know so much of it is wrong.
Yet I have perhaps 10 times more knowledge and quite a bit more experience in regards to software development than I did just 3 years ago.
So what gives?
Overall, I think I am giving better advice based on more practical experience and knowledge, it is just that I am far more aware of my own short-comings and how stupid I am even today.
I have the curse and blessing of knowing that only half of what I am saying has any merit and the other half is utter crap.
Much of this stems from the realization that there are no absolute right ways to do things and best answers for many of the problems of software development.
I used to be under the impression that someone out there had the answer to the question of what is the right way to develop software.
I used to think that I was picking up bit of knowledge, clues, that were unraveling the mystery of software development. That someday I would have all the pieces of understanding and tell others exactly how they should be developing software.
What I found instead was that not only does nobody know the “right” way to develop software, but that it is perhaps an unknowable truth.
The best we can do is try to learn from obvious mistakes we have made before, start with a process that has had some level of success, and modify what we do based on our observations.
We can’t even accurately measure anything about software development and to think we can is just foolishness.
From story points, to velocity, to lines of code per defect and so on and so forth, all of those things are not only impossible to accurately measure, but they don’t really tell us if we are doing better or not.
So, what is my point?
My point is simple.
I have learned that not only do I not have all the answers, but I never will.
What I have learned is always subject for debate and is very rarely absolute, so I should have strong convictions, but hold onto them loosely.
And most importantly, don’t be deceived into thinking there is a right way to develop software that can be known. You can improve the way you develop software and your software development skills, but it will never be based on an absolute set of rules that come down from some magical process or technology.