2018-01-05

LinkedIn, Titles, Roles, and the nature of work.

Titles are like animals that we keep around because we are amused by them. You never quite know what they're going to do, or how they're going to effect your life, but a lot of people really seem to like them, and pay a whole lot more attention to them than they're actually worth.

Recently I've spent a lot of time at a company that barely recognizes that titles exist, internally. Everyone can chime in about anything. People may look at you a little odd, but it's true, and certainly interesting to have that level of exposure. Sure, there's some churn due to information flows, but people tend to self organize by interest, rather than specific role or title.

This has made me reconsider how I think about titles, and in particular what I should put on LinkedIn. I try to keep my resume as up to date as I can, but when you work at a company that is a Holacracy, you can't quite pigeon hole yourself with one particular role/title. I've gone through a bunch of iterations on what I think I am, as a software developer...
  • Junior
  • Mid-level
  • Senior
  • Architect
  • Principle
But what do any of these really mean? They're supposed to indicate a level of capability within your given field. They might just do that if you're an Accountant, or perhaps in certain lines of business. They simply don't map very well on to the abilities of a programmer. For example, I've met people that call themselves Principle Software Architects. What does that mean? That they're really good at making flow charts? Do they even code? As another example, I've met Junior Developers that are far more capable than your average Senior Developer. These dichotomies exist all over the place, of course, but it's quite stark in software. It's far more important how your thought process works, than how long you've been able to call yourself a developer.

So I've decided to take a new track for LinkedIn. My primary title is now 'Thinker, Problem Solver, and Writer of Code'. I think that best describes what I do, in respect of how important they are. Without considering problem spaces, you can't even come up with problems to solve, and when you're solving problems, sometimes it'll involve code. Occasionally. Too often people rush to write code without considering whether or not they really need to, and that's one of the things I like to think hard about. 

The only code you don't have to support is code not written.

That doesn't mean I'll remove all my titles from individual positions, but I do think it's far more important than all those position names, combined.

2017-04-27

It's been a little while since I've written, but recently I've been hearing a lot of interesting app ideas from people, and I've been asked why an app may or may not succeed. These are the two questions that I ask them, when I hear, "Hey, I have an idea..."

1. How is your app going to shortcut some pre-existing habit or work for an individual?

You can't add more work to the day. People just wont do it, and it'll be a struggle all the way. The only way you get to add work to peoples day is via legislation, or some kind of rule that has enforcement. Otherwise, people are lax and will forget to do it, or simple choose not to. Make sure they want to do it. The only way you can make sure of that, is to make some existing work easier.

There are some applications that seem like they've gotten around this theory, particularly in the social sphere. Arguably, social application are shortcutting communication and socialization. You're "reaching" 10x the people in the same amount of time, though you're giving up the human touch to do it.

The other question is:

2. Where's the money?

Money is how apps get built, and how they survive. It's impossible to keep an application running if money isn't flowing in. This could be from any number of sources. Ads, subscriptions, one time purchases (not a good idea!), partners, or even some corporate sponsor.

Without a clear idea of where the money to build and maintain your application is going to come from in the long term, it probably wont get off the ground. Further, if it seems like you have an answer to this question that involves some kind of connection to an industry, you need to follow that up with, "Who has the connections to make this happen?"

If you can't answer these two questions clearly, concisely, and deeply, your idea needs more fleshing out before you can move forward. Unless you want to constantly be funding the app with your own time and money.

Once you can get past these two questions, refer back to my previous blog post for ideas on how to more deeply flesh out your idea!

2016-01-15

Modernizing the "Joel Test"

Most developers have heard of the "Joel Test". At least, those developer that have spent much time researching development methodologies and keeping their finger on the pulse of tech in the past ten years. Developers are always looking for ways to evaluate places that ask them to do work, and I am no different. The thing is, some of those items don't necessarily apply to the modern development environment, so I've updated it for 2016. I've also weighted them so that it's clear what is a necessity, and what is a nicety.

Must Haves


  1. Are you an agile shop?
  2. Do you have a well defined audience for your product?
  3. Do you have a product owner?
  4. Do you use version control for all code? Distributed version control?
  5. Do you utilize Continuous Integration (CI), or even better, Continuous Delivery (CD)? 
  6. Do you keep an up to date issue database? 
  7. Do you do hallway usability testing?
  8. Do you have the best hardware and software that money can buy?

Nice to Haves


  1. Are you profitable?
  2. Are developers encouraged to actively participate in requirements gathering?
  3. Do developers have quiet working conditions?
  4. Do you allow developers to work from home?
  5. Do you have a schedule?
  6. Are there product testers?
  7. Do candidates write code in their interview?
  8. Do you provide training opportunities for your developers?
  9. Do you encourage writing unit tests for all features?

As I see it, on the "must have" list, you really should be able to answer every single one of those with a yes. If not, you're going to need a really good explanation. If it's more than one, you probably have a serious problem on your hands. On the "nice to haves," slightly over half would probably suffice, but really, you should try to hit them all. If you want to be competitive in the market place, and a good place to work, you'll want to make sure as many of these are true as possible, along with being in the top 25th percentile for compensation. It is a very competitive market for engineers, and anyone that isn't providing proper care and feeding of their development staff will soon find that someone else will.

Of course, these are all open to subjective interpretation, because each developer will have their own ideas, but let me provide you with my take on why each of these are so important.

Must Have #1 - Are you an Agile shop? ("a"gile? Scrum? Kanban?)

Waterfall is dead, long live waterfall. It's been nearly two decades since Agile was coined, and still many shops haven't implemented it, and many developers haven't been trained in it. Even if you don't subscribe to a particular set of practices (a la Scrum), lets hope that you at least know and live by the agile manifesto.

Must Have #2 - Do you have a well defined audience for your product?

In order to be able to know how to build your product properly, you're going to need to know exactly who you are marketing your product to. If you don't fully understand who you are marketing to, then you need to go back to the ideation stage of your product, and figure that out. If you can't answer that question thoroughly, you can't move on to development.

Must Have #3 - Do you have a product owner? Bonus points for documenting requirements.

Many products have languished in software purgatory over not having a visionary that is leading the development of software. This is because every point of software development is about managing trade offs. If you don't have someone with a firm grasp of where you are going, you'll never know what kind of trade offs that you can make.

Must Have #4 - Do you use version control for all code? Distributed version control?

Software is part of your companies DNA if you're hiring software engineers. First and foremost, you should be making sure that you're keeping full control over that software that is being produced. That's only a side effect however. Primarily, the purpose here is to enable and facilitate efficient and consistent collaboration between software developers. That is its number one duty. Without a solid version control system and process in place, crashing and burning is all but inevitable.

Must Have #5 - Do you utilize Continuous Integration (CI), or even better, Continuous Delivery (CD)? 

This is all about the build. You should be able to build immediately on check in. If you can't do a build and check to make sure all your tests pass, at the least, you're not going to have any level of code quality that is being ensured. This is the first step towards a well tested piece of software, without it, it can fairly be assumed that testing is discouraged passively, if not actively.

Must Have #6 - Do you keep an up to date issue database? 

If you don't know what your bug trends look like, it's hard to tell if you have a fairly solid piece of software. Further, if you don't have a strong understanding of how many bugs are in your system, you'll have no idea if you should be actually doing deploys. This should guide every step of your development process.

Must Have #7 - Do you do hallway usability testing?

Developers should constantly be bugging the product manager, or at least doing usability tests between themselves. To make sure that what they're building fits in with expectations of others. If not, it's very easy for them to go off the rails and build something that they think is neat, rather than what the product actually needs.

Must Have #8 - Do you have the best hardware and software that money can buy?

This should be a no brainer. If you're going to pay a software engineer six digits per annum, don't skimp on the things that they need to do their job. 5% of salary yearly budget seems like it would be a start, though a stronger offering would be 10%. This is the primary way to show that you really want a developer to stick around. Removing any possible roadblock to them doing their job. Computers and software are the tools of the trade. Don't offer, or accept, anything less than the best.

Nice to Have #1 - Are you profitable?

Many companies aren't. That's fine, but you need to have a really strong reason that you aren't profitable at this time, and have a path to profitability in the near future. Or at least a way to be certain that you can make payroll. If developers aren't confident that they'll receive their paycheck, you can assume their eyes will be wandering.

Nice to Have #2 - Are developers encouraged to actively participate in requirements gathering?

Product managers, business analysts, et al, can theorize all day long. Unless a developer is actively involved in their ideation efforts, and helping to keep ideas firmly grounded in reality, you could end up handing requirements to a developer that will take them months to implement. Even years. If they even are capable of doing so. Developer feedback should be highly encouraged.

Nice to Have #3 - Do developers have quiet working conditions?

Despite many trends that are going in the opposite direction, developers need quiet time. This is how the magic happens. If developers down have quiet time where they can be heads down and write code, they wont be able to get their job done. Over collaboration slows down production just as much as being completely out of sight and out of mind. Slack, and tools that assist in communication, but don't interrupt flow, are perfectly suited for interacting with developers. They don't require instant reaction, but they aren't email, which can be completely overlooked.

Nice to Have #4 - Do you allow developers to work from home?

There is no intrinsic reason why development needs to be done at a shop. Or even from the same continent. That's why offshoring was so popular for a while. That said, there are reasons to get together and make sure that 'the magic is happening'. Office space can certainly be used for that purpose, but it shouldn't be thought of as 'where the magic happens'. The magic happens wherever development happens. For some people, that's harder in a sterile development atmosphere. Flexibility is key.

Nice to Have #5 - Do you have a schedule?

If your software lives on a schedule, is it posted? Why is it scheduled? Remember that agile development is all about working software, customer orientation, and responding to changes. Deadlines and plans are all guesswork and, in many cases, wishful thinking. Sure, you can have some idea of what you want done, and by when, but that doesn't mean that it'll happen. Good software takes time, and if you have your audience right, they're going to be happier waiting for solid software, than complaining about software that isn't working correctly.

Nice to Have #6 - Are there product testers?

Sure, developers can test software, but they're very myopic. They only see the feature that they just implemented, and don't tend to look at the bigger picture. Some developers manage that, but they're a horse of a different stripe. A unicorn, so to speak. Ideally, someone from your target audience would perform user acceptance testing at a minimum.

Nice to Have #7 - Do candidates write code in their interview?

How do you know if a given developer can code? You ensure that by actually having them write you some code. Keep in mind that if you do it during the interview, it's very likely that they're extremely stressed from the interview experience itself, and wont be operating anywhere near 100%. You could alternately offer them a code test on off time, or just have them explain a code project that is all their own that they could walk you through. Either way, you want to see some kind of code from the developer. Would you trust a designer that didn't show you a portfolio? Probably not! Same goes for developer.

Nice to Have #8 - Do you provide training opportunities for your developers?

Developers have serious upkeep requirements. One of the big ones is making sure that they're staying up to date. This means giving them opportunities to learn now things. This can take the form of a 20% rule, like Google. Or it could be conventions. Any number of ways, but developers should always be investing in themselves, and this is how it is done.

Nice to Have #9 - Do you encourage writing unit tests for all features?

Tests aren't really optional anymore. Software moves too fast in the modern era, and you need to be able to test it at every step of the way, and be confident that it works as expected. Without tests, your confidence level diminishes rapidly. You should be writing tests for all new features, but if you aren't, you better have some other very serious testing plans at hand.

2015-11-03

Inception of an Application


As software developers, we're consistently asked to 'just build this thing'. I used to find it somewhat flattering that people would believe that I could help them realize their dreams. After years of talking to people about their ideas, and occasionally offering to help out, I came to a much different understanding. It was less flattering, and more frustrating. It's like asking a construction worker if they would build you a high rise. Maybe that'd be nice, but it's a dream. Without backing, it's like being asked to help them win the lottery. The person asking often just doesn't have any conception of the time and will that it takes to bring about an application. So I thought I would write this introduction to what it takes to get a developer interested in building your application, and why the magnitude of the word 'just' is staggering.

While this first post is more clearly aimed towards the person that is new to the SDLC (software development life cycle), it may have some insightful points for the seasoned programmer that isn't accustomed to reflecting on why they should build their own applications. Either way, lets hop right in.

When you feel that stirring that you think you might have an idea for a piece of software, you need to start answering questions about it. Usually before you even bother anyone else with it. It needs to become an object in your own mind that you can spend time carefully questioning and scrutinizing. Turning over each facet and understanding what you have, even before you bring it to other peoples attention. These five questions should lay a solid groundwork for refining the startling clarity that you will need:
  1. What is it that you want? Hint: This answer should be personal, and probably long form.
  2. Who is your audience? Apps are not all that different from books.
    1. Why will the audience care? 
    2. How will it save them time, or improve their process?
      Remember: People wont use your software if it doesn't improve their life in some way.
  3. Why is it worth doing, what is going to make it be amazing? Don't be circumspect.
  4. Where will the motivation come from? For you and anyone else working the project.
These are reflective questions, not meant for easy answers. If you believe that you have found an easy answer, then you probably need to go back to the drawing board and keep brainstorming. These questions should generate a lot of thoughts as you really start to understand your idea. Paragraphs worth, perhaps. Once you feel you have a solid understanding, then the next step is to distill these answers down to a 5-15 second elevator pitch. Something reasonably easy and quick for your target audience to understand, but leaves them wanting more. This is not the pitch you should use on developers. Most developers have a finely tuned BS-o-meter, and wont be interested in a sales pitch.

Once you're comfortable that you have a solid pitch, then you should move on to keep questioning your idea with deeper, more incisive questions. While these aren't prescriptive, they're a great starting point for things that you'll definitely need to understand:
  • Who is your audience? Dig in to them. If you think you have multiple audiences, make sure you go over them all.
    • Why do they care? What are their motivations?
    • Why will they use your software daily?
    • How is your idea better than your competition? And don't fall in the pit of 'There's nobody else doing this'. There's always someone providing some kind of competition.
  • Will this software have a revenue stream?
    If yes (and 99% of the time, if you're not the developer, it should be yes): 
    • Where from? Sales? Ads? Grants?
    • Why will they give you their hard earned money?
    • How much will it generate? And don't be coy.
    • Is that worth up-keeping for at least 7 years? Think maintenance and return on investment.
    If no:
    • Where there is no money, there darn well better be a strong motivator. What is it?
    • How will you host and maintain the software if you have no money?
    • How will you get developers interested, and keep their attention?
    • Are you really sure it's worth keeping up for at least 7 years?
  • When do you want it by? 
    • Are you going to need resources/money to develop it? 
    • Where are those resources going to come from?
  • Finally, and most importantly, how will you know when you have your desired software?
These are just stepping stones to get you moving in the right direction at a high level. They're thinking points that will assist you in figuring out what your starting point looks like, and deciding if you are willing to be in it for the long term, and if you'll be able to actually get money out of your product.

If you've made it through this entire process, only then should you really think about involving a developer. Understand that you're talking to someone that can help you realize your dream, but don't imagine you're asking for a dog house, when you're actually asking for a high rise, and remember that they're not likely to build a dog house for free, much less a high rise.

2015-10-28

Assembled Best Practices for Software Development

I've been curating a list of my favored practices for some time now. These ideas have come from a variety of sources (books, blogs, coworkers, myself, etc.). These make up some of the best ideas and practices that I have seen in software services. There are a whole lot more that I could talk about, but these are the most important that I think everyone that works in software development should be familiar with. Without further ado:

Understand the foundation. This can be one of the most glaringly obvious, yet oft overlooked, points of an application. Every application has a goal; Something that it aims to do better than anyone else. Generally, that goal leads towards two or three core competencies that the whole platform will revolve around. Make sure you know what those competencies are, and don't ever sell them out, or outsource them. Your evenings and weekends depend on it.

Features are like pets. They're fun! But, they have to be groomed, cared for, and carefully maintained. As such, like pets, you should be very careful about which ones you adopt. Whenever someone says, "We should add.." always start with "no". Make any non-core feature work to be in your application.

Scratch your own itch. The next big thing is a lie, and doesn't deserve your attention. Make something that saves you time, and makes your life better. There will always be people trying to figure out how to force the next application to blow up in to something big. Instead, just figure out what your itch is, and scratch it.

Always Be Shippin'. Too many projects die before they even get off the ground. Figure out what the minimum viable set of features are, and then ship it as quickly as possible. After that, iterate on the design, and make sure you get it in front of your (preferably paying) customers, right away! They'll love you all the more for seeing your software evolve in front of them. Speaking of which:

Love your audience. Your software is nothing without your customers. Focus on their needs and collaborating with them, more than the amount of money, or the contracts that they bring in. When they give you information, respond to it. The most important lesson of sales is to remember this one simple truth: People don't buy a product, they buy an emotion. Make them feel good over and over, and you'll have a customer for life.
 
The customer always believes they are right. But, they're probably not. That's right. Conventional wisdom is wrong. That doesn't mean you treat them as if they're addled. On the contrary. You should always treat your customers with dignity, and respect, if not admiration. Yet, even when you do that, you should help them understand why your software works the way it does, and don't let them dictate terms that will lead you in to a feature haze. That way only leads to heartbreak. Listen to your customer, ask pointed questions, and act only when it is in the best interest of your entire audience. Never become myopic, as that always has an effect on the picture as a whole.

Build simple systems. Some will find it frustrating or condescending, but building three ways to do the same thing in your system doesn't make you nicer, it makes your system more obtuse. Find one way to make your system do the best possible work, and make it as intuitive as you possibly can.

Estimates are pure guesswork. Don't fall in to the trap if you can help it.  Keep shipping features as you are able. If someone makes you guess how long it will take you to implement a particular feature, imagine how long it will take, then weight that by somewhere between 1.5 to 5 times that number, depending entirely on your own personal expertise and the complexity of the system at hand. If you think something that you're not very familiar with will take you a day and you're dealing with a complex system, don't feel bad about saying five days. If it's something you're very comfortable with it's not complex at all, and you think it will take two hours, go with three. The key is this: Always under promise and over deliver. People may think you're daft when you guess five days, but they'll think you're a miracle worker when you deliver it in two, instead of grumbling about it taking twice as long as one.

Remember these three things:
  1. There are things that you know that you know.
  2. There are things that you know that you don't know.
  3. There are things that you don't know that you don't know.
That last category is the largest of the three, guaranteed.

Finally, the best way to learn is to practice, scrutinize, adjust, and repeat. Don't just keep doing same thing that you've always done, else you'll always get what you've always got.

Code on. 

2014-05-12

How Java and Ruby made me a better Node developer

Herein is a partial recounting of the bits and bobs that I have learned passing through different programming languages. Principles and processes that I found useful, and not so. It is by no means a complete recounting, but rather meant to help people understand why it's so important to try new things, even when you think you've 'got it down'. How each culture brings new and innovative ideas that can better your code! Onward...

Just shy of a decade with Java

There are many things to be said in favor or against Java. While I personally have no plans of returning to the language in the mid-term future, I learned many things from it and the connected community.

The Java Virtual Machine is a rock. Meaning, it is a very suitable foundation upon which to build the next generation of languages, much the same as C is. It allows highly portable code to be crafted such that it can be highly performant on just about any system that the JVM runs on, in languages (groovy, scala, clojure, jruby, et plus..) that are much more terse and flexible.

Everything in Java-land is configurable. This can be both a boon and a bane. Many Java libraries take their configurability to the point of absurdity, which in turn leads to codebase bloat. Spring is a fantastic example of this. It started off as a great DI platform, and ended up with nearly a J2EE level of complexity and in-and-of itself requires hundreds of megabytes of space on disk, not even to speak of once it gets in to memory. It is not desirable that every library should cover every possible option.

The Java community has a love for design patterns. I was first exposed to many useful patterns that I still use in other languages while I was in Java, here are a few that I still use quite regularly: MVC (or rather, variants thereof), Observer, Messaging, Facade, Factory, and Flyweight. Many of the others still apply, but aren't as useful when you have a greater syntactic flexibility. Realizing that these patterns are available to me has been a great help. When I am trying to reason through particularly difficult problems, I can fall back on some of these great patterns and find possible solutions. Unfortunately, the Java community takes this to an unhealthy level in a lot of cases. They get bogged down in talking about patterns instead of solutions. As martial arts masters say, first you have to learn how to do it, then you have to unlearn how to do it, and just do it.

Document all the things. When you work with so many highly configurable pieces of code, you have to make sure you know exactly how to make those libraries perform as you wish. The Java community is fantastic at generating vast quantities of documentation. There is a lot of white noise when you going looking for a specific problem that you have, but more likely than not, someone has your problem documented, somewhere. You just have to dig hard enough to find it. There are many communities that could learn from this approach.

Boilerplate is bad, mm'kay? Strongly typed languages require lots of it, no matter how you slice the problem. Particularly when trying to encapsulate absolutely everything. My take away from this is that boilerplate, while sometimes necessary, is an undesirable. If you find yourself constantly writing the same pieces of syntax over and over, you're probably just wasting your time and making your code more complex. Sometimes the solution is to refactor. Sometimes you need to re-evaluate the tools that you're using.

No conversation about Java would be complete without mention of their dogmatism. This was one of my greatest take aways from the Java community: Don't adhere to dogma. More than that, don't listen to appeals to authority. Just because it's writ in an RFC somewhere, doesn't make it the right way to do something. The Java culture takes their 'thou shalts' to an unhealthy level, and they end up writing massive amounts of code in order to prove their adherence.

Two years in Ruby

Ruby was built with developer happiness and ease of use in mind. It is an object oriented language that inherits a lot of its thought processes from Smalltalk. It was my first completely object oriented language, and I must admit that I found its terseness to be a breath of fresh air when I first joined the world, after so long in Java. When I was first coding for the web using Perl and PHP, and then went to Java, I thought for a very long time that it was going to be almost impossible to go back to a dynamic language, due to how poorly written "all dynamic code" was. Due to my experiences with Perl and PHP. Oh how wrong I was, but it took me a good amount of my own personal time, and jumping off the cliff in to enterprise Ruby to truly find out how "ready for prime time" that these new dynamic languages have become!

While I was not originally exposed to the Pareto principle ("80/20 rule") in Ruby, it was the first time that I saw many libraries trying to follow its advice. While controversial to many people, I saw this work out very well for a lot of cases. Take ActiveRecord for example. That library makes it very easy to do basic database queries against any number of relational databases, but if you need to do something more specific with a database, like call a stored procedure, you can just use the connection directly. Rather than them trying to encapsulate that functionality somehow.

Convention over configuration. A phrase that seems to have come directly from the Ruby community as far as I can tell. Those involved in Ruby still build some fairly large libraries (though nothing alongside the monolithic ones that are in Java), but they provide sane defaults. A good portion of the time, even if you're using a fairly impressive sized library, you can start with just bringing it in and using the default settings that it provides. This language was the first that I had seen that provided these sane defaults that you didn't have to shepherd and tweak to get just right.

Keeping it Simple and Stupid is a mantra for the Ruby community. That's where a lot of the innovation that people hear about from Ruby-land comes from. Don't overbuild. As DHH said, Rails is omakase. Don't like ActiveRecord? Don't use it. Need to kick some processing out of your web worker thread? Great, put it on a queue somewhere for a worker to pick up- but don't overbuild that queue. You should have sane defaults so that you can get a worker on that queue almost immediately. Anything else is overbuild and waste of time.

Two very important acronyms: DRY (Don't Repeat Yourself) and YAGNI (You Aint Gunna Need It). These two are mantras that I find myself repeating constantly while I'm programming. "Do I need to be able to do that with this piece of code? ..Nope!" And, when I start to copy and paste a set of code, or start retyping code that I know is elsewhere, I immediately stop myself and start refactoring so that I only have one set of code performing any particular function. I can't even begin to recount how many times this has saved my bacon when hotfixing applications.

Rails Style: "Skinny controller, fat model". This means that you should put your business logic, or the logic that actually performs changes, in the model. The controller shouldn't be overbuilt, it should only contain enough code to tell the model what to do with itself, and then pass the information back up to the client. I think that this doesn't go far enough some times. There are usually opportunities to improve even further on this during fairly complex processes. Rather than expanding a model in to quite large proportions, I occasionally take a cue from the Java land and write up a service layer instead. So that you're not bloating your controller or your model to an unmanageable level.

While the Ruby culture is not quite as dogmatic as the Java culture, they still definitely believe there is a right way and a wrong way to build your applications. Particularly if you live in Rails-land, rather than one of the subcultures (Padrino/Sinatra, for example). Still, the Ruby culture is more palatable and less stogy than the Java one in my estimation.

What's more: The Ruby culture taught me that development can be fun again. I blame that expressly on the fact that so few "paycheck developers" spend their evenings learning Ruby, so it is a group of enthusiasts instead of people that are looking for their next gig.

A year of Node

My introduction to Node came when I started using it regularly as tooling, which I do believe is how it is getting its induction in to a lot of development groups! Whether it is setting up an asset pipeline (grunt/gulp), or giving you a foundation for your next web application (yeoman), or managing your front end javascript dependencies (bower), there are a lot of uses for Node without even utilizing it as a primary language. That's a pretty big win. Once somethings starts to feel familiar, you can't help but start be curious about how more of it works. Eventually, I decided to take the plunge. I'm glad I did, despite some of the pundits that speak of Node's insufficiencies.

So far in my time spent in Node, there are two big things that I have taken away. One of which I've mildly hinted at from the Java and Ruby sections: Modularity. Ruby still has some fairly large large stacks that it requires one to use. While Rails is not one monolithic framework, but a collection of fairly large frameworks, it is still nearly 200mb in memory when it is first loaded. While memory is cheap, and disk is too, I still don't believe that relieves us developers from paying attention to those numbers.  When I first built an express application with Node and it used less than fifty megabytes from the get go, I knew I was hooked. Sure, there are some lighter weight frameworks in Ruby and Java, but that's not really how their communities think. The strongest and most active communities in Node revolve around the ExpressJS foundation. The primary application that I support today is less than 150mb with all code, in memory. The largest node app that I maintain doesn't go over 300mb in memory until it starts taking requests. I remember one java gig that I took, and they had a server with 32gb of memory for me on my first day, because the application itself took up more than 8gb in memory... I still look back and shake my head.

Asynchrony is pure win, but has its trade offs. It comes at the cost of comprehension. It can be harder for the developer to reason through, when nearly everything is an event (everyone that has spent much time in JavaScript has heard of "Callback Hell"). Despite that, there are many advantages of having your code being non-blocking. The scalability characteristics for any program that has to spend any time in wait cycles (and any program that accesses a database spends lots and lots of time waiting) is losing a lot of computer cycles just sitting and waiting for that response. Node takes full advantages of that time spent waiting to do other things, instead of making them wait in line. This is primarily achieved with the heavy use of streams. Any non-trivial application will eventually end up doing some work with them. It'll probably bend your mind a bit at first, but eventually you'll see the light At this point, I'd have a really hard time justifying going to an "IO Blocking" language again, having seen the ease with which Node can scale.

And.... That's a Wrap!

Phew! That was quite a bit! I hope you found this review interesting, or at least a bit insightful. Feel free to leave me a comment either way, I'd like to hear what you think. Either way, I would encourage you to not get too comfortable where you're at. Keep pushing the boundaries. Keep innovating. Because that is what being a coder is all about.

2014-05-09

Getting Uncomfortable: Three Years in Retrospect

It's been years since I've written in this blog, yet I feel that many of the things herein have bared out to show what I was originally speaking of. Particularly with regards to my predictions of CoffeeScript. There are more options than ever for writing JavaScript with syntactic sugar: CoffeeScript, Dart, TypeScript... Pretty impressive for a dynamic language!

It can be a little scary jumping in to a new pool of knowledge, even if some of your old knowledge still applies. That's how I felt when I left behind Java, and dove in to the wide world of Ruby, and even more so later when I dove in to Node.

Minneapolis is not a "technologically innovative" part of the country. The majority of developers that live in this area are mired in technologies that are "safe" or "proven" rather than pushing the boundaries. Though I'm not sure Ruby counts as pushing the boundaries, considering that it has been around since 1994, and Rails has been under active development since 2004. Somehow that still qualifies as "new" technology in a lot of peoples eyes. I can only imagine what they would think of those writing applications in Node, which was first released in 2009! 

Somewhere along the line there was a shift in technology culture. I can't imagine anyone that was in technology during the 70s and 80s having the same thought process. They were chomping at the bit to push the boundaries of what can and should be done. We wouldn't be where we are today without those innovations. Sure, not everyone can be on the 'wave' of technology. There have to be many holding down the old tech, keeping it all under control. The change has become fairly clear. What's more, it's surprising how many greenfield projects end up choosing Java or .Net as their building blocks. Because it's what they have used for more than a decade.

With that as background, here is what I can tell you about living in the dynamic language world:
  1. Don't hesitate to use Ruby or Node for your next production application. If Github, New Relic, 37Signals, and Ravelry can scale Ruby, so can you. If Paypal and Walmart can scale Node, so can you.
  2. There is massive scalability with some of the new frameworks out there, without having to stand on your head while holding three blocks with your feet. Worry more about your problem domain, and choose tools that help you solve those problems swiftly. Speaking of which:
  3. Time has a cost. It's called opportunity. When you spend time writing an application 'the only way you know,' and that way takes a factor of 5 times longer to build the application, you need to find a new way. Give your idea life, don't let it flounder in a quagmire of "we've always done it this way".
  4. Embrace new ways of thinking. Every time I have adopted a new language, it has brought new thought patterns to light, which in turn makes my code better, and thus my end product stronger. 
Don't be skeptical of new technology, embrace it. Try it. Extend it. How do you think the Java and .Net platforms grew to be the size they are? Because people with their own visions were constantly hacking on them. That's the way they managed to mold the subculture. Maybe you don't like what Ruby brings to the table. That's understandable, but standing still is not. Try Python instead! Too mainstream? Sure! Try Node! The asynchrony will make your head spin. JavaScript not your thing? Okay, but I think you're just making excuses now: Try one of these powerful languages: Elixir, Erlang, Go, or Rust! It's an exciting time for developers. There are so many new ways to build massively scalable applications. Take up the challenge! Don't eschew the new for the old. Get out of your comfort zone. See what's out there. 

You will be better off for it. Even if you never deploy a production app with it.

Stay tuned for my next post: How Java and Ruby made me a better Node developer.