Tag Archives: languages

10 Ways to Learn New Things in Development

Expanding upon one of the topics in my post about 5 Attributes of Highly Effective Developers, I’ve been thinking of various ways to kick-start learning opportunities in my career and hobbies.

1. Read books. There are tons of books about programming–probably most of them are useless, but there are many, many gems that can greatly influence your abilities.

I still find that it’s easier and faster to find information about many topics in familiar books than to find similarly valuable information online. Read all your books to get to this point.

Books are also valuable from theory, architecture, design point of view. There just aren’t that many places on the web to get high-quality, authoritative instruction in this.

Like this? Please check out my latest book, Writing High-Performance .NET Code.

2. Read Code. This is something I was late to. I didn’t start reading a lot of significant code until after I had a few years of professional programming experience. I would be a better programmer if I had started earlier. I try to read some source code every week (not related to work, not my own, etc.) from an open source project. Start with programs that you use and are interested in. I started with Paint.Net and it solidified a lot of .Net program design technique for me.

Reading other people’s code shows you different ways of doing things than you might have thought of on your own.

3. Write Code – Lots of it. Fundamentally, the best way to learn something is to do it. You can’t fully internalize something until you’ve written it. This starts with something as simple as copying the code examples from tutorials and books. That’s copying by hand, not cut&paste. There’s a difference. The idea is internalize and think, not blindly copy. Look up new API calls as you go. Tweak things.

Most importantly, develop your own projects–whether they’re simple games, participation in an open source project, or a simple plug-in to a program you use.

Try to use new technologies, new techniques, new designs–do things differently. Do things better in this project than in previous ones.

This is really the core point–if you want to be a better developer than develop.

4. Talk to other developers – about specific problems you have, as well as the latest tech news from [Apple|Microsoft|Google|Other]. This not only helps you feel part of a team or a community, but exposes you to a wide variety of different ideas.

Different types of projects require different designs, coding techniques, processes and thinking.

If you work in a small team (like I do) and you don’t have access to many other people, go find some at a local user group meeting. If nothing else, participate in online forums (you’ll have to look harder for an intelligent discussion).

5. Teach others. Similar to just reading code versus writing it, teaching other people can do wonders for forcing you to learn a topic in depth.

The very idea that you’re going to have to teach a topic to someone else should force you to learn something with a far better understanding than you might otherwise. You can face questions.

If you can’t explain a concept to a 6 year-old, you don’t fully understand it. – Albert Einstein

Teaching situations are myriad: one-on-one with your office-mate, water-cooler meetings, informal weekly gatherings, learning lunches, classrooms, seminars, and more.

How about setting up a once-a-week 30 minute informal discussion among like-minded developers? Each week, someone picks a topic they want to know more about and teaches it to the others, instigating a conversation. If you knew were going to teach the group about synchronization objects, don’t you think you’d want to understand the ins and outs of critical section implementation?

6. Listen to podcasts

If you’ve got time where your brain isn’t otherwise occupied, subscribe to podcasts. My current favorite programming-related one is .Net Rocks. They also do a video screen cast called dnrTV.

These will help you keep up on the latest and greatest technologies. You can’t learn everything and podcasts are a good way to get shallow, broad knowledge about a variety of topics, from which you can do your own deep investigations.

If there are other, high-quality developer podcasts, I’d love to hear about them.

7. Read blogs

There are more blogs than people to read them, but some are extremely well-done. I’m not even going to post links to any–there are plenty of other resources out there for that. This is one of the best ways to connect to people who actually develop the software you love and use.

8. Learn a new language

If all you’ve ever done is C(++,#)/Java there are a LOT of other ways to think about computer problems. Learning a new language will change the way you think. It’s not just a different syntax–it’s fundamentally rewiring the brain. Sure, all languages get compiled down to assembler in the end, but that doesn’t mean a high level abstraction isn’t valuable.

Functional, query, and aspect-oriented languages are starting to merge with C-based languages–are you ready?

9. Learn the anti-patterns

Aside from knowing what to do, learn what not to do. Read Dailywtf.com often and take the lessons to heart if you don’t already know.

It’s all well and good to understand proper OO design, coding style, and what you should be writing, but it’s easy to get into bad habits if you’re not careful. Learning to recognize bad ideas is vital when taking charge of a project.

Wikipedia has a thorough breakdown of many common anti-patterns,

10. Be Humble

Learning means:

  • Replacing faulty knowledge with better knowledge
  • Adding knowledge that you do not already have

There’s no way to learn until you admit you have some deficiencies. It all comes back to humility, doesn’t it? If you ever start thinking you know everything you need to, you’re in trouble. True learning is about hungrily seeking after knowledge and internalizing it. It takes lots effort. We all know this in theory, but we have to be constantly reminded.

Fighting Brain Rot

Alex Shalman has a great post at zenhabits about how to avoid letting your brain decay into apathy and atrophy. It’s a great call to action, to find ways of self-improvement. I think the behaviors listed here dovetail very nicely with the attributes of highly effective programmers.

By continuing to do as we always have, the quality of results will be the same as always. Only when we step out of our comfort zones, and push ourselves to improve, will we gain useful new experiences, knowledge, and ideas.

I think the methods of expanding the mind are highly applicable to software developers. I just have a little bit of commentary on each one.

11. Reading – I think I would have put this at #1. It’s the easiest way of cramming information into your skull. It’s the most efficient method of information transfer, and that’s our bread-and-butter as programmers, so we should become expert at it.

10. Writing – We write code for a living, not necessarily prose, but communication is key to so many areas in life, that learning how to write effectively is critical to most careers. For myself, I definitely find it easier to express myself in writing than in-person. Doing this well becomes a critical ability.

9. Puzzles – Developing a large software project is in many ways like an enormous software project. It’s so large, though, that we can’t comprehend it all at the same time. But practicing other types of puzzles can train our brains to look for patterns and to develop new, creative ways of thinking. My favorite offline puzzle is the New York Times Crossword, but I enjoy the occasional sudoku.

8. Mathematics – a good understanding of boolean logic, prepositional calculus, discrete mathematics, asymptotic notation, etc. are great things for developers to have. A general understanding of algebra, calculus, trigonometry, and statistics also comes in handy more-than-occasionally. Another valuable idea that comes out of mathematical understanding is the idea of precision in thought and rigorousness in testing or understanding your software–think loop invariants.

7. Painting – I am definitely not an artist by any means, but the underlying principle of some kind of artistic self-expression is important. The creative side of your brain must be regularly exercised. For me, this is in the form of building Legos.

6. Cooking – I initially found this to be a peculiar choice, but it makes more sense when I ponder it. Cooking is at once creative and precise. Not only does it use all the senses, but it requires you to think on your feet and be very, very organized and detail oriented, especially when you start cooking for more people. Planning and execution both become huge issues.

5. Music – I wholeheartedly agree, and I’ll even go out on a limb and say that you need to listen to lots of genres of music, especially classical. Why classical? Because it exhibits more musical complexity than all others. It doesn’t minimize various musical aspects (variation, melody, harmony, tempo, timbre, i.e.) for the sake of a single one (i.e., rhythm).

4.Poetry – I used to write fiction and poetry in high school and earlier, but it’s been quite a while. I do remember it being quite the exercise to compose sonnets–it forces you to be extremely creative with grammar, syntax, meaning, vocabulary, and more.

3. Meditate – This is an art I need to learn more about. I find I do this automatically in some situations where I’m not otherwise preoccupied (the shower), and I can solve a question I’ve had. I find that NOT doing something is as important as doing something in many cases. When I’m faced with an especially thorny problem at work, it really helps to just write down my thoughts about it and let it sit for a few days while I think about it in my off moments. Most of the time, I can come back and have a better solution than if I had started right away.

2. Learn a language

A language that doesn’t affect the way you think about programming is not worth knowing. – Alan Perlis

The original article obviously means foreign spoken languages, which I definitely agree with. I speak Italian, and the insights it’s given into my own native English are quite valuable. If you’re a careful student, knowing two languages definitely forces you to think about the meaning of words and constructs. It’s much harder to take things for granted.

I think the same is true of programming languages–knowing more than one helps your mind think about a problem in different ways. Once you understand functional programming, for example, you will never look at programming the same way again.

1. Question Everything – This is analogous to love of learning in my Effective Programmers essay. It’s not being a jerk and denigrating everybody else’s ideas. It’s asking yourself continual “Why” questions in order to understand the issue.

Technorati Tags: ,,,,

Managing Complexity – Part 2

Last time, I covered some generalities and anecdotes about minimizing complexity in my life. Today, I have a few more thoughts about complexity as it relates to software.

Software engineering has continually evolved since the inception of computer programming languages. One way of looking at that evolution is to see it in terms of improvements on complexity management. (This is a bit simplistic, since computers have simultaneously become much more complex.)

The first computers were simple by today’s standards, but the programming methodology was very complex: dials, levers, buttons, or physically connecting wires. Then machine language was developed binary code could be entered on a card, later memory, and interpreted.

These early languages required a perfect familiarity with the machine. If the machine changed, the code changed.

Over the years, the advances in languages have largely been a process of hiding the machine’s underlying complexity. ALGOL came around and hid the machine code and provided the foundation for FORTRAN and C. C built further by providing both structured programming tools and an abstraction of the machine’s language–one foot in each world.

Terminals began to have graphics capabilities and SmallTalk was developed to further hide the complexities of both growing code modules and user interface elements. Java hid the complexities of lower-level code like C and C++, and even took away the concept of a physical machine and substituted its own virtual machine, theoretically consistent across all physical platforms. C# has done much the same for Window–hiding the complexity of thousands of APIs in a hierarchical, intuitive framework of managed code.

Modern processors are beasts of infinite complexity and power compared to the early hulking iron giants, but the languages which we use hide nearly all of the complexity that our forebearers had to deal with on a daily basis.

Now it looks I’ve been really writing about abstraction. It’s extremely strongly related, but I don’t think it’s exactly the same thing. Abstraction is thinking at a higher level; minimizing complexity is thinking less.

Modern languages both abstract away lower level concerns and provide tools to minimize the complexity of things at the highest level.

There is increasingly a proliferation of visual tools, begun with GUI editors, but now including visual code designers.
Aspect-oriented programming and attributes are allowing complexity to be further minimized.

In the future, tools such as these, and increased use of COTS will become vital to accomplishing anything. Software complexity will only increase, but hopefully the trend of tools that minimize complexity will also continue.

Perhaps somebody (not me!) should investiage the theory of a total complexity quotient–a measure of the complexity of a system and the complexity of the tools to develop and manage that system. With this number we could measure if complexity overall is increasing or decreasing, and what/when is the crossover point.