I’m not saying never again to owning an iPad. The newer, fancy models with the pencil cast a certain spell on me.

Still, I reached a point where gadgets are only added to my collection if they get used. So I’ll only get an iPad if I can find a workflow that makes it a necessity.

In doing so, I fear a seed was planted. I started asking myself what said workflow might look like.

What is an iPad useful for?

iPads tend to be great consumption devices. They are lightweight and easy to transport. Fast, thanks to great specs and tight integration with the operating system. Their battery life lasts for most of the day. If you are watching videos, casual browsing, or playing games they are quite convenient.

I don’t hate consumption, but I’m trying to focus more on production than consumption in my life. So the iPad doesn’t hold great appeal when solely considered as a consumption device.

In recent times, I have seen people use them to be more productive, however. Doctors and medical students appear to be quite fond of domain-specific apps as well as its note-taking capabilities. Digital artists create great paintings and drawings on them. Musicians and even photographers/videographers are increasingly using the iPad, particularly the Pro line, on the go.

Could the iPad be a great option for programming as well?

My ideal use case

Before we discuss how one might configure an iPad for programming, I’d like to point out that my primary use would be reading technical PDFs, annotating them, and taking notes. If you are only interested in programming, laptops are a superior choice.

Still, you are there sitting at the library or a coffee shop. You’re reading a programming book, jotting down notes. It’s only natural to want to write code to validate and experiment with what you’re learning.

We know from neuroscience studies that the act of taking notes by hand is superior to typing them when it comes to retaining the information. For programming related material, however, I’d say that writing actual code is just as important.

You could bring both a laptop and an iPad but it becomes quite inconvenient at that point.

So for me, the ideal scenario would be an iPad that allows me to read technical books, annotate them/take notes, and program on it.

It already excels at the first two tasks, but can the iPad work for programming? The screen, in landscape mode, is certainly big enough. If you opt for the 12.9″ model, it’s essentially no different than my current MacBook Pro. Spec-wise, it might even be as fast, if not faster.

So it’s really a matter of software. These babies should be called iFortKnox. They are quite locked down.

A possible iPad setup for programming

If you search for them, you’ll find the occasional IDE for iOS. Pythonista for iOS, for example, will mostly work if you’re writing Python scripts.

Unfortunately, there isn’t an equivalent for Elixir and Phoenix, which I tend to favor these days. Plus, I like to use Git as a mechanism to share code between different laptops.

VNC is not a great option either, in my experience. You’ll face quite a bit of lag and the smaller screen of the iPad doesn’t lend itself too well to showing a whole computer desktop.

It seems to me that the best approach is to have the development environment on a remote machine and use the iPad as a client.

Amusingly, dedicated services like C9 by Amazon do not support mobile browsers that well. Though, with the upcoming iPad OS defaulting Safari to a full browser, it’s possible that these will become a viable option.

Based on my research, the most promising alternative is running a cheap remote box on DigitalOcean or similar provider, and connecting via a mosh-shell like Blink Shell. That appears to work really well even with spotty connections.

It would mean using a terminal-based editor. It’s not for everybody, but even though I tend to use Visual Studio Code these days, I would have zero problems with using Vim for this purpose. (Hello Vim, my old friend, I’ve come to type with you again.)

This caveat aside, I really don’t see a downside to this workflow. I get all the benefits the iPad brings plus the ability to actually do real programming (with a cover keyboard, of course).

The new iPad Pros are rumored to come out soon. They might be announced in less than two weeks. So I’m going to sit tight on this one but I’m eagerly waiting.

What about you? Do you have an iPad? Do you use it for programming? Is your workflow different than the one I propose here? Let me know in the comments below.

The post Programming on an iPad appeared first on Programming Zen.

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. Incidentally, this ends my one-year hiatus from blogging.

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

The method of human communication, either spoken or written, consisting of the use of words in a structured and conventional way.

The second definition is more interesting because it allows me to make a point about programming languages. It goes like this:

The system of communication used by a particular community or country.

Look at that. Isn’t that beautiful? Let’s cut the country stuff, and shorten it to, “The system of communication used by a particular community”. Tell me that it’s not a spectacular definition of programming languages as well.

We can look at programming languages in two possible ways. They can be a means for us to instruct the computer, and incidentally communicate with fellow programmers, or they can allow us to communicate with other programmers in specific terms that are ultimately executable.

The first interpretation is technically more accurate. Or, more specifically, the worst kind of accurate.

I like to think of programming languages as languages because, outside of trivial programs, above all else they enable programmers to communicate with one another when it comes to resolving a problem or completing a particular task, while incidentally producing code that is also understood by computers via “translators” (e.g., compilers and interpreters).

There are plenty of benefits that can be derived from thinking about programming in terms of the second interpretation.

When you view programming in this light, you start considering the value of comments expressing the “why” and code expressing the “how”. Tests become a way to communicate to a fellow programmer [1] that a change to the codebase has violated a given requirement. Above all, writing idiomatic code becomes important.

Remember the Google Dictionary definition. “The system of communication of a particular community”. It is in fact the community, for better or for worse, that sets the guidelines and de facto style of a particular programming language.

Since we are operating in a system of communication, programming is a bit like driving: predictability is important. That’s why in the Ruby community we have the principle of least surprise [2] and in the Python community one finds the “There should be one – and preferably only one – obvious way to do it” mantra. [3]

When you think of programming languages as a series of conventions adopted by a community, and incidentally understood by the computer, you avoid recklessly monkey patching classes just because you can. You know that doing so leads to unexpected results and miscommunications with other programmers.

You also avoid features which are technically legal in the language, but rare and confusing to fellow experienced developers in that particular language. For an example of this, take a look a the Flip-Flop operator in Ruby (a reminiscence of its Perl heritage). Technically legal Ruby, even useful at times, however you shouldn’t use it because only a handful of fellow Rubyists will understand what you’re doing. [4] Worse yet, it will be hard to Google for an answer unless you are familiar with its name already.

When you’re first picking up a human language, you learn the meaning of common words. Then you use simple sentences that you memorize from books, people around you, songs, movies, and TV shows. Then you try to mimic the idioms you see used by mother tongue speakers. Often you won’t get them right at first, resulting in comical variations that are close, but not quite right, to those of native speakers.

When it comes to programming languages things really aren’t all that different. That’s why it’s critically important to read other people’s code, write code and receive feedback in code reviews, do peer programming, take part in open source contribution, and engage in other forms of social interaction pertaining to code. Doing so is immensely important when it comes to truly mastering a programming language.

Another consequence of this emphasis on communication among programmers through a common, precise, language whose style, conventions, and idioms are defined by the community is that you should choose your communities carefully. What are the community’s priorities? If there is no love for beautiful, clear, elegant, easy to understand code, tread very carefully. [5]

As someone who had to learn English as an adult, pretty much from scratch, I can tell you that I find many parallels between the experience of learning a new language and that of a new programming language.

Even if the two are not a perfect match – and seeing a programming language as a human language is an imperfect metaphor – I feel that thinking of it in these terms has allowed me to quickly acquire key skills in the programming languages that I needed or wanted to learn.

The post On Programming Languages as Languages appeared first on Programming Zen.