DEV Community: Antonio Cangiano

25 Pitfalls When Learning to Program

Antonio Cangiano — Thu, 09 Nov 2017 21:47:41 +0000

I’m going to share with you what I see as “25” common pitfalls when learning to program (or working towards mastering programming). Many of these points affect both beginners and professionals alike — myself very much included.

0. Forgetting that programming is all about people. Yes, the machine will execute your code, but programming is solving problems for people, translating their requirements into code that will be read, maintained, and modified by other people (or yourself down the line).

1. Not spending enough time programming. Depending on your job or schedule, you might spend a lot of time on tasks that are related to programming but aren’t actually programming itself.

2. Stopping at the surface of a given technology you’re learning. Feeling satisfied with having mastered the basics just enough to get stuff done, without ever exploring further or going behind the scenes all that much.

3. The Magpie approach to learning programming. You start learning Rails, half-way through you realize that Phoenix is out there, oh and you need to learn JavaScript so you might as well go with Node.js. But wait... TJ switched to Go, and hold on… what about Rust? Soon enough your browser history will have, “web development or data science career”, “is Clojure dead?”, “Clojure vs Elixir”, “is Crystal mature enough”, “any good frameworks for Golang”, “Phoenix vs Buffalo” and “Kotlin for web development” all in the same week. :)

4. Reading books and watching courses online but not practicing the skills presented, therefore quickly forgetting about them.

5. Skipping fundamentals. So you end up learning about continuation-passing style (CPS) but still can’t do SQL joins without an object-relational mapper.

6. Not enough patience or discipline to progress through the learning process and steps required to master any technology.

7. No clear map or schedule for continuing to learn through available resources, while you tackle more immediate challenges in your day-to-day programming.

8. Analysis paralysis, wasting way too much time choosing amongst various frameworks and libraries (like Angular, React, and Vue), rather than just picking one, using it, and switching to something else only if you actually need to do so. Basically being a maximizer instead of a satisficer.

9. Refusing the polyglot nature of modern-day programming. In most domains, it isn’t reasonable to expect one programming language to be the best fit for every problem. Likewise, identifying too much as an X or Y programmer, rather than just a programmer who prefers X or Y.

10. Fear of experimenting with new technology. Rather than just reading about certain emerging technologies (e.g., blockchain or chatbots), actually firing up a VM to try them out yourself, even if it involves getting your hands dirty with a programming language or API you are not familiar with.

11. Expecting to know everything upfront. Being disappointed after finding pointers to the solution via Google, because you didn’t come up with an elegant solution entirely on your own and kicking yourself while thinking, “I should have thought of that myself”.

12. Not creating many small katas, exercises, and projects while learning.

13. Fear of sharing code with others or getting code reviews, lest you be judged.

14. Not seeking one-on-one mentorship from more experienced developers.

15. Expecting to learn everything at once with unrealistic timelines (e.g., master iOS development in a month).

16. For the more entrepreneur-minded, not exploring cool projects because they don’t have a clear path to revenue generation.

17. Not asking questions for fear of coming across as stupid or as more of a newbie than you actually are.

18. Feeling like you are not a real programmer if you’re creating apps by gluing high-level libraries together, in a high-level language instead of doing “hardcore” algorithms in more complex languages. I dub this low-level programming envy.

19. Allowing the desire to learn best practices to hinder your ability to grasp the fundamentals of a given language or technology. For example, feeling like you need to learn a whole book on design patterns or master TDD/BDD before you start creating projects.

20. Perfectionism. Letting perfect be the enemy of good enough. Never shipping anything, getting stuck in the “final touches” phase. (But balance is important, so don’t ship horribly broken software for the sake of shipping.)

21. Related to the previous point, ignoring the progression: make it work, make it faster, make it clean. Instead, expecting a polished solution from the get-go. It’s important to accept that the first iteration will be a rough draft to improve upon.

22. Impostor Syndrome. Feeling that you aren’t good enough. This is particularly bad if you don’t fit the current developer stereotype, as a lack of role models that you can relate with might mistakenly confirm your doubts. This is part of why women and minorities representation in tech is so key.

23. Writing code and learning about programming from books, but never reading other people’s code. Open Source gives us an amazing resource that can drastically speed up our understanding of programming and best practices.

24. Not getting exposed to other paradigms or domains. If you’re a web developer, not learning about other types of development. If you know Object-Oriented programming, not learning about Functional programming.

25. Not teaching others what you learn. Nothing will solidify what you learn as well as trying to explain it to others. Even just studying with the intention of teaching will increase your ability to learn.

There you have it… 25 pitfalls. Oh, don’t forget off-by-one errors, too. ;)

Conclusion

All this to say:

You’re good enough. You can definitely do it. Just watch out for these pitfalls, make a plan, commit to it, then take it one step at the time.

When learning to program (or improving your current mastery of it), I recommend the code/read/teach method. Code one real project, and many small exercises/katas as you learn. Read books but also other people’s code. Finally, teach what you learn online and in person. You don’t need to be an expert to do so.

I hope this is somewhat useful. If it is, feel free to share the link online. It’s a list that I, myself, plan to reread once in a while.

Initially, I shared these thoughts on learning to program as a series of tweets, but Twitter’s UI had some issues displaying them as a single thread. So I’m reposting them here as a post.

The post 25 Pitfalls When Learning to Program appeared first on Programming Zen.

So You Want Your Programming Language to Be Popular

Antonio Cangiano — Thu, 18 Aug 2016 20:32:10 +0000

Some programming languages become popular. Others don’t. Why is that? Are the popular languages better than the obscure ones?[1] It’s more complicated than that, so let’s grab a long stick and poke at this hornet’s nest.

Define popular

To start off on the wrong foot, there isn’t really a consensus on the popularity of programming languages. There are various efforts to rank them based on Google searches, StackOverflow questions, GitHub repositories, and so on.

Depending on which heuristics you consider and how you weigh them in your ranking, you’ll end up being biased in favor or against certain languages.

For example, there is an obvious correlation between the popularity of a programming language and the number of relevant questions on StackOverflow. However, all things being equal, this metric will penalize simpler and better-documented languages.

If you take GitHub repositories as an indicator of popularity, you’ll penalize languages for which code tends to be hosted elsewhere. The same applies for languages that are not widely used in the open source world, of course.

Thankfully, we don’t need exact rankings in order to have a meaningful conversation. Let’s just agree that the ballpark definition of “popular”, as far as this article goes, is making the cut in the top 20 on the TIOBE index or the Redmonk index.[2]

Are popular programming languages better?

Popular languages are not necessarily better than less popular ones.

I would argue that the Lisp family is, in many respects, one of the best family of languages. It is, by our definition above, marginally popular at best.

Without any intent of starting a flame war, I feel obliged to point out that PHP is one of the most popular programming languages in the world.

Technical merit alone doesn’t separate the winners from the losers. Let’s see what does.

Default languages

Several of the most popular languages in the list(s) are what I would define as default languages.

Default languages are the natural go-to language for a given platform.

For example:

C is the default language for Unix system programming;
JavaScript is the default language for web browsers;
SQL is the default query language for relational databases;
Java is the default language for Android apps;
Swift (and before that, Objective-C) is the default language for iOS and Mac applications.

Default languages are popular because anyone who is interested in developing in a given ecosystem will simply default to them.

They have a massive advantage over alternative languages.

Using something else requires research and effort. To borrow an example from within the tech world as well, BASH is far more popular than the arguably superior ZSH and FISH shells, simply because it’s the default on so many *nix systems.

Languages backed by tech giants

Another category of popular languages are languages backed by tech giants.

Note that it is not merely sufficient to be backed by a large tech company. Think Google and Dart (particularly prior to Flutter). No, to make it popular, the company must put their weight behind the language.

Microsoft pushed C# so hard that it virtually became a default language for Windows programming.

Large standard libraries

With the exception of select default languages that rely on their positional advantage, most popular languages have a large standard library.

You need to have one in order to appeal to the initial seed group of developers who will, in turn, help you grow the ecosystem of libraries.

Python is the perfect example of this. Its “batteries included” philosophy made it useful from a very early stage. A great seed for the vast library ecosystem that would develop.

Often new languages that have emerged and become popular in recent years have leveraged existing platforms as a mean to provide a large standard library and a well-sized ecosystem of libraries right off the bat.

The most common examples are languages for the JVM, such as Scala, Clojure, and Groovy.

Give it a few more years and Elixir might become an example of a popular language on BEAM (the Erlang Virtual Machine).

Paradigm shifts

Sometimes programming languages become popular because they provided an answer to a particular paradigm shift within the industry.

OOP (e.g., C++, Java), the emergence of the web (e.g., JavaScript, Perl, PHP), mobile programming (e.g., Objective-C, Swift, and more recently Kotlin to some degree), the emergence of data science (e.g., R), come to mind.

Paradigm shifts don’t occur too often, but when they do, they open the door to new languages.

Right now, functional languages have a shot at widespread adoption. In part, because they work so well within an increasingly concurrent and parallel world.[3]

Killer apps

Which bring us to another reason why some languages succeed in terms of adoption.

Having an absolute killer application within a given domain.

Ruby is the poster child of this. Outside of Japan, it was a largely ignored language for a decade or so before it started to gain traction elsewhere.

Then Rails came along – and it was a very compelling proposition for web development.[4] People were impressed enough that they were willing to study this little-known language called Ruby, simply because of Rails.

And when they did, they discovered what a nice little language it was. Its technical merits were fundamental to its adoption (and the reason why DHH picked it up for Rails), but not sufficient on their own.[5]

It’s not an overly common scenario, but languages which provide a better answer to a specific problem within a popular domain can experience huge gains in popularity.

What else helps? Marketing.

Marketing helps. A community that doesn’t shy away from good technical marketing will undoubtedly help the language become more popular.

Note that marketing is a very encompassing term. Great documentation is good marketing. Not having to spend an hour installing things just to get started is arguably part of your approach to marketing.

Being accepting, inclusive, and welcoming to newcomers is good marketing. Blogging, organizing conferences, giving speeches at other conferences, writing great books, are all good examples of things a marketing-oriented community does.

What else? Familiarity.

Familiarity is very important. If your programming language is radically different from anything that the majority of developers are used to, it will struggle to become widely adopted.

So it has to toe the line. It has to be innovative enough to make it worthwhile, but familiar enough that it won’t immediately induce a negative gut reaction the moment a new developer approaches it.

This is a struggle numerous Lisp languages have had to face. Most developers are familiar with the Algol/C syntax, however, S-Expressions are somewhat scary and foreign to many.[6]

Because of this, although functional languages have a shot this time around, it won’t be an easy sell.

Anything else? Time.

Programming languages don’t become popular overnight. It takes years, no matter how you slice it.

Most languages take at least 10 years to become widely adopted. Adoption rates are getting faster in recent years, but this process still takes quite a while (several years).

The most obvious exception is Swift, with its meteoric rise over the course of just a couple of years of its introduction. Not only Swift is backed by Apple, it was also made into a default language for one of the most popular development ecosystems in the world.

So if you’re a programming language developer or an early adopter of a language that you wish to see become more popular, be patient. You’re in this for the long haul.

Popularity ain’t easy

It’s really hard to make a programming language popular.

The competition is fierce, with so many valid options available to developers.

As we asymptomatically approach all that programming languages can be, it is even harder to create something that’s so very much better than it’s worth making the leap to.

Developers need compelling and convincing reasons to jump ship or even just consider investing time in your language and community.

Consider for a moment why a programmer would want to learn a language that is new to them:

To get or keep a job;
To become more productive and/or write better software;
To develop a new category of applications;
To learn a new paradigm.

If your language can satisfy at least some of these needs, it will have a chance. But this only buys you admission to the race.

Conclusions

In summary, I believe these are the key factors to consider:

Being a default language for a popular ecosystem;
Being backed and promoted by a tech giant;
Having a large standard library and/or targeting a popular VM (e.g., JVM, unless it’s a system language like Rust);
Fully embodying a new paradigm shift;
Being very useful in a particular domain, like Ruby did through Rails back in 2005;
Having great documentation, guidance for newcomers, tools, editor integration, and in general removing any instrumentation obstacle that makes getting started with your language difficult;
Fostering a welcoming and inclusive community that encourages sharing, marketing, and evangelism;[7]
Having a somewhat familiar syntax that is easy to read, write, and teach;
Being active and developed for several years;
Providing technical innovations that lead to productivity and more maintainable code;
Luck.

The first two are out of the question for most languages, and even then, few languages will meet all of the remaining requirements.

Even embracing just a few of these should, however, be enough to grant your language a chance at becoming mainstream.

Failing that, you might still be left with an active, niche language that will survive and be appreciated by many developers for decades to come.

It’s worth noting that this same question can be posed in wildly different fields. What makes certain musicians popular? How about cars? In this article, though I will discuss my thoughts on programming languages in particular. ^
An alternative heuristic is to consider a language as being popular if there are multiple current books on the subject published by the most prominent tech publishers such as O’Reilly, Wrox, The Pragmatic Bookshelf, Addison-Wesley, No Starch, Manning, etc. ^
In part, because we have come to appreciate some of their features that were incorporated in more mainstream languages. ^
Whatever you think of Rails today, it has significantly affected the world of web development for the past ten plus years, almost regardless of the language you develop in. ^
I have said before elsewhere that Rails is both a blessing and a curse for Ruby. It’s a massive blessing because Ruby owes so much of its popularity to Rails. It’s a curse because such a focus on web development within its community has led to limited applicability outside of the realm of web development. Python was spared by such a fate. ^
It’s remarkable how popular Clojure has managed to become despite its Lisp syntax. A testament to how many other things they got right. ^
There is a fine line between being enthusiastic users and brigading other communities. Always be respectful of other communities and don’t arbitrarily spam your language around. ^

The post So You Want Your Programming Language to Be Popular appeared first on Programming Zen.