JavaScript Patterns - From Padawan, to Jedi master

I recently purchased the JavaScript Patterns kindle edition written by Stoyan Stefanov. I had read his Web Performance Daybook a couple of months ago and it was a good read. So I had feeling this one's going to be worth my money.

Now it's often difficult to find good intermediate to advanced technical books that help you get over the hump. I have about read 90+ computer reference books, and this is one of my favorites. If I were to  sum up this book's review in a single line then "Each time I reread the book, I learn something new. ”

This is a nice thin book suggesting useful patterns and coding practices in Javascript. It clearly explains the occassional unexpected features of the Javascript language. If you’re looking for best practices and powerful patterns to help you write better, maintainable, robust JavaScript code, this book is for you.

What to expect from the book? (abstracts picked from book)


Some of the basics (like loops, conditionals, and closures) are not discussed at all. If you find you need to brush up on some of those topics, refer to either JavaScript: The Definitive Guide or JavaScript: The Good Parts. At the same time, some topics (such as object creation or hoisting) may look too basic to be in this book, but they are discussed from a patterns perspective and, in my opinion, are critical to harnessing the power of the language.

His chapters on Object Creation Pattern is exceptionally good where he explains namespacing, dependency declaration, module pattern, and sandbox patterns. All these help you organize and structure your application code and mitigate the effect of the implied globals. Other topics of discussion include private and privileged members, static and private static members, object constants, chaining, and one class inspired way to define constructors.

When talking about Code reuse pattern, the first thing that comes to mind is inheritance, and a great deal of his chapter is dedicated to this topic. You see several ways to do “classical” and nonclassical inheritance. But it’s important to keep the end goal in mind we want to reuse code. Inheritance is one way (means) for us to reach that goal. And it’s not the only way. The author shows how you can compose objects from other objects, how to use object mix-ins, and how you can borrow and reuse only the functionality you need without technically inheriting anything permanently.

Purchasing the Book

All-in-all, I would highly recommend this book to anyone seeking a comprehensive knowledge of JavaScript and best practices. Within a few minutes you can take your knowledge of JavaScript from intermediate to advanced. It does; however, require a good understanding of the language.

Are Good Programmers Good at Maths

I was reading an interesting argument on SO. The topic of discussion was that conventional wisdom suggests that good programmers are also good at math...Or that the two are somehow intrinsically linked. Many programming books I have read provide many examples that are solutions to math problems, or are somehow related to math as if these examples are what make sense to most people.

So the question is: do you have to be good at math to be a good programmer?

It all depends on what you want to do as a software developer.

If you want to go into graphics, you need a strong background in geometry, linear algerbra, matrix tranformations, (physics wouldn't been terrible either) etc. If you want to go into SQL or other types of database programming, logic (proofs, inference laws, etc) and Discrete Mathematics (maybe even lambda calculus) are all necessary.

As far as being a programmer in the business world goes, I would say that the answer is NO. You can become a great programmer without knowing advanced mathematics. When you do end up having to deal with math, the formulas are usually defined in the business requirements so it only becomes a matter of implementing them in code.

How about a Math mindset?

Most people think of math as doing arithmetic or memorizing arcane formulas. This is like asking if you need perfect spelling or an extraordinary vocabulary to be a good writer.Writing is about communication, and math/programming is about the process of clear, logical thinking (in a way that you can't make mistakes; the equation doesn't balance, or the program doesn't compile). Specifically, that logical thinking manifests in:

• Ability to estimate / understand differences between numbers: O(n^2) vs O(lg(n)), intuitive sense of KB vs MB vs GB, how slow disk is compared to RAM. If you don't realize how tiny a KB is compared to a GB you'll be wasting time optimizing things that don't matter.
• Functions / functional programming (is it any coincidence that the equation f(x) = x^2 is so similar to how you'd write that method? The words "algorithm" and "function" were around in the math world far before the first computer was born :-))
• Basic algebra to create & reorder your own equations, take averages, basic stats

So, I'll say you need a math mindset, being able to construct & manipulate mental models of what your program is doing, rather than a collection of facts & theorems. Certain fields like graphics or databases will have certain facts you need also, but to me that's not the essence of being "good at math".


I'll quite happily admit I've never particularly liked maths or been good at it (I actually graduated with a degree in Political Science!) and have worked as a professional developer for over 18 years now. I develop mostly web applications, which rarely require that much maths. More important is the ability to think logically, be able to break problems down into chunks and have a wide understanding of the various technologies and frameworks involved.

As a programmer you are much more likely to have to implement an existing algorithm than devise an entirely new one. Need to work out, say, compound interest? You don't need to figure it out yourself, just look-up the formula and apply it. Most of the problems have already been solved, you just need to know how to implement the solutions in your language of choice. That's not to say that being good at maths wouldn't be an advantage; it's just that it isn't totally essential.

When I was at school in the mid 80's when home computers where not very common I often wrote programs to solve my maths homework. I often couldn't do it in my head, but I could apply whatever formula was required as a software routine. You don't need to be another Pythagoras to work out the longest side of a right-angled triangle, you simply need to be able to code up a² + b² = h² in your language of choice.

Conclusion

You don't have to be good at math. However, you have to be good at logic, and problem solving. Some would argue that people who are good at logic and problem solving are usually good at math also. I would say that it really depends on the type of math. You can be terrible at calculus (like me), and still be a good programmer (like me). But if you have trouble with Discrete Math and Set Theory, you would probably find a lot of aspects of programming quite hard.

Honey, I Introduced Agile In My Company

People are always resistant to change, and moving to scrum is a pretty big one. Motivation and direction are key.

My group has recently grown in size with the addition of several teams from different projects. We work using an Agile programming methodology: 2 week sprints, deliverable every sprint, 2-3 pushes to production every sprint for each team. A challenge we face is to "convert" the newly added teams to this methodology and way of thinking with as little trauma and resistance from the members of these teams.

The first step is to get people motivated to give scrum a chance. Start with people who you feel will be receptive to the change whether they are developers or managers, so you can build some momentum. Getting managers on your side going to be a necessity at some point, but how you handle that depends on your environment.

After that, everyone needs to be trained, whether it means reading a book or having a lecture series. Unless people know how scrum works, you cannot start trying to implement the process. They won't "get it" right away. That doesn't matter -- explanations don't really help as much as simply doing it. Get them started with daily standups today. Immediately. No waiting around. No "conversion". Just start.

Agree to just one sprint to get started with a reasonable scope of work. They'll completely mess it up, but that's okay.


The best way to learn Agile methods is to just start doing Agile methods.

Here are 6 practical tips that may help you out

• First get management backing. If you don't nothing else will make up for this one.. If the upper level is all 'The deadline is yesterday..', 'Working weekends for the next 3 months', 'Why are you writing tests when you should be coding?.. we can test later.' The dodo simply won't fly.
• See if the culture of your organization is suitable for agile. This was something I missed.. To borrow a line from the book.. The process will be easier-faster if the culture supports and nurtures new ideas, allows time for people to learn and do new things, is patient enough to support innovations with long term benefits and does not consider failure to be a death sentence
• The People: Identify the innovators : early adopters : early majority : late majority : laggards ratio. The first 3 are your target audience initially.. should be around 30-40%.. that gives you the critical mass to get rolling. The trouble is Agile turns the spotlight on the elephants in the room.. deficiencies and issues become easily visible.. if you live in a place which has had a "Bozo Explosion" (to quote Guy Kawasaki's term), the change would be really slow and painful.. if at all. We have a tendency to assume that if an idea is good, it'll be accepted. Not true. Lots of sociological reasons raise their heads.
• Next don't try too many things at once. Take it slow.. take it easy. The trick is to use a refactoring-legacy-code-like approach. Find little wounds here and there and patch them with an agile bandage. Make sure that the people understand the practice and benefits and they should adopt them over time. Not everything will stick but soon it becomes better on the whole. How soon depends on a number of variables some of which are out of your control.
• Its a huge personal investment to make this happen. Re-examine if you are willing to make this committment and go through the ups-and-downs it brings. Also you may have to hand over the baton to someone else or a higher up.. Be prepared to relinquish change ownership for the greater good. Don't fall into the 'Its my baby' syndrome.
• Agile is different for each team, each organization. Not everything you read/propose will work.. let acceptance guide you towards the things that will work for your scenario. Find other ways that compensate for the practices that didn't take root.

You can't heal what you can't feel

Building trust with you team members and keeping them motivated is of utmost importance. Once people are motivated and have an idea of what they need to do, you need to have your first planning meeting and set up the necessary parts of scrum (scrummaster, daily meetings, etc.).

I would expect that the first planning meeting will not go smoothly, and will be a learning experience for everyone. Also the first few sprints will be very rocky, and probably behind schedule. The key part now is discipline and persistence. Do not let daily meetings run too long, keep the planning meetings on task, and make sure everyone is doing their roles correctly. With past successes and having the trust of both your team and your manager, they will look to you when it comes time to make decisions.

Lastly I'd just say be very empathetic. I made the mistake of dismissing most ideas before I'd really though them through because I didn't read about it in "XYZ agile book." Listening to your team & trying to implement some of their suggestions will go a long way.

Agile for small teams of 2-3 people

If you are a very small team of 2-3 people, you sure can use certain agile principles in your projects, you don't have to use scrum, use whatever will work best for you. You can definitely benefit from some of XP methods and some scrum practices. But probably not "by book", 1-2 person team is just too small even for that little overhead scrum brings, start with what book says and then drop whatever you'll feel irrelevant after some time. Just don't drop retrospectives, it sure is worth the time spent discussing the problems you have, and finding solutions for them.

Agile techniques are suited to smaller teams as with larger teams it becomes more difficult to manage communication. With 1 or 2 people developing a project (and a customer) you should be able to work in an agile manner very easily. i suggest you read the agile manifesto as a good start to agile. For scrum, I'd suggest you look at Scrum from the trenches. Kanban seems to be in fashion now and there is a personal Kanban too!

Agile for the Solo Developer

Here are some tips to implement Agile processes for the solo developer:

• By doing test-driven development
• By developing in small sprints, maintaining a sprint burndown and a product burndown - A sprint burndown starts with a list of all tasks you've decided to complete in this sprint (a subset of your product backlog to be completed over a set period of time - e.g. 2 weeks) along with the estimate of the work required. As you mark things off, you mark them as done; thereby reducing (or burning down) the remaining work for that sprint.
• Similarly, a product burndown tracks the remaining work for the whole product backlog
• By having a lot of contact with the customer
• Keeping a product backlog - A product backlog is basically a list of all items you intend to complete at some stage for this product.
• Adopting the concepts of relative estimation and velocity - Relative estimation is an estimation technique that uses the other tasks (or stories) as a guide. For example, if you know task A is easier than task B and about as twice as complex as task C, you'd make sure the "points" for task A were correct relative to those expectations. The emphasis is not on correctly guessing the amount of work required, but keeping estimates consistent with each other. Velocity is a measure of how many "points" you get done in a sprint. If your relative estimation is ensuring consistency, this velocity can be used to estimate which tasks you're likely to get done in the upcoming sprints. Note though that velocity should be constantly revised.

 I found this conference talk which should help you out: Personal Kanban: Optimizing the Individual Coder

Personally, I have seen more abuses in the name of agile than I care to write on. Many times "we're doing agile" means "we're throwing away all semblance of process and doing what we want, Yeehaw!" (for the obvious cowboy reference). An agile environment definitely helps, but you have to allow for developers to talk to each other and hammer things out--without scrum dictator approval.

Agile is about incremental development in a field of changing requirements, not about dictating people how they individually go about doing their work.

References: Practices of an Agile Developer, Collaboration Explained, Agile Retrospectives: Making Good Teams Great, Stackexchange, Agilescout