The thing with code clarity: you can't be proud of something I can't read

Einstein once said:

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction.

I'm pretty sure Mr. Einstein didn't write code for a living, but for someone like me (and probably you), who has written and seen a lot of code, these words resonate like they were meant for software developers.

There are many + 1 books out there talking about the importance of code clarity. There are even more articles, videos, blog posts, conferences, and people talking about this same topic, but somehow it feels that is not enough.

I read code every day, and it still looks complicated, convoluted, disorganized, and stitched together with disdain. I keep talking to people that don't get it, or don't care, or that just don't understand how to make it better.

And I know I won't fix it by adding another blog post to the pile, but I can't just shut up. Instead, I hope somebody reads this and decides to do better. At least for some time, or maybe for just a day. Who knows; it might change something for good.

Why people wouldn't shut up about code clarity?

Coding is not only about telling a computer what to do, but about telling people what you are trying to get done with a computer.

Remember, developers will come and go. Bugs will show up. New features will be added. Hours and hours will be spent working with the same code, growing and stretching it. You better feel comfortable with it now. You better make it easy for those who will help you later.

If your code is hard to understand, it will be easier for people to make mistakes when changing it. Others will be scared of it. They won't like to change it and make it better, so it will rot and get worse with the time. Something that started as a single complicated line will eat your system from the inside out, one line at the time.

Clarity prevents bad stuff like this from happening.

My code is as bad as my neighbor's

Personally, I don't think my code is as clear or simple as I would want it to be. I've written really scary software all my life, and I don't feel proud about it.

Years have gone by and I'm definitively getting better. Every time I'm sitting in front of an editor, I make an active and conscious decision of using my code to tell a story.

I want people to read it and enjoy it as much as I do. I can't get there if they don't get it, so I try hard, very hard, to make it easy for them.

And just like you, I can do better. I must if I want to keep growing as a developer. At one point it stops being about how much you know and it starts being about how well you do what you know.

I believe I'm right there.

For those who don't care

Have you ever seen this quote?

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

It was Martin Fowler who said it. And he is a very smart fellow, so you should take note.

Imagine talking to an architect that wouldn't shut up about the looks of her building, totally neglecting the fact it was built on a shaky foundation that will collapse sooner rather than later.

What's in the inside is usually as important as what you see. Developers first and foremost write code. They should love it and all the process that goes into creating it. If you can't feel proud about your code when showing somebody else, how can you call yourself a developer without blushing of disgust?

Remember that complicating your code doesn't make you smarter. Instead it shows how immature you are as a software developer, and puts a huge red expiration date in front of it for everyone to see.

For those who don't know how to do better

I've noticed that a lot of people struggle with making their code legible for others. It's a hard thing to do, and it requires time and a lot of practice:

I would have written a shorter letter, but I did not have the time.

The above quote is attributed to Blaise Pascal, who wrote it in 1656. Being concise when writing takes time. It's also difficult to write short, clear, and easy to understand code.

But all the effort you put into it is so worth it!

As I mentioned before, I always try to make my code tell a story. I want people to read it and completely understand what, why, when, and how things are happening. Every time I look back and see something I can't read, I refactor it.

I use comments when necessary, only to explain things that I can't or don't know how to make clear enough, but I'd rather make my code reveal its intention through the use of better naming conventions, proper structure, and correct spacing and indentation. Every bit helps, and I use whatever I have to make it easy on the eyes.

I pay special attention to what I call tiers of complexity. People reading my code for the first time are usually looking for the 10,000 ft view version of what my code does. This is my first tier, where I try to be as humane as possible with my narrative. When people want more, they can start digging deeper into subsequent tiers, where more details are revealed by the code. The further you go, the more complexity you'll uncover, one tier at the time.

I can't finish this post without recommending Refactoring: Improving the Design of Existing Code. Read it. Over and over again. It will help make your code so much better!

I hope this inspires you

If this post helps or inspires at least one developer to take a second look at a pice of code and make it better, I'd be extremely happy.

I'm zealous with my code. I nurture it from the very first line until I'm done. I want it to be my résumé, to speak for me in front of anyone trying to decide whether I'm a good developer. And I want you to feel the same way.

From all the great stuff out there available to us, learning how to write clear and maintainable code is something that will last with you forever, and it will make you so more valuable.

So please, look into it. One single line at the time.

Running queries in BigQuery from the command line

I know you can do this with the bq command line tool, but if you need to run queries from a Windows shell (which sucks), and you have complicated enough queries (several pages long), you might want to consider this script.

(I tried, and had to write this instead. The Windows shell complained all the time with the quote symbols used by the queries, and having to format the content to fit in the command line wasn't a fun task.)

I'm sure that if you are smarter than me, you'll be able to figure out the bq tool, but if you don't have the time to spare, go to GitHub and download this project: query-bigqueries.

The README.md file does the rest

The README.md in the project explains all you need to know to run the script:

  1. Create the authentication JSON file
  2. Create the file containing the query you want to execute
  3. Run the script

The result of the script is a comma-separated list of all the fields returned by the query.

Why the script?

At work we have several reports that we run periodically. Each one of these reports spits out a .CSV file. The content, of course, is coming from BigQuery tables.

We set up several scheduled tasks that run the script with all the queries we need to run. We pipe the results of each query into the corresponding .CSV file. Simple and efficient.

I hope is useful for you as well.

It's a matter of time: the web will also win the mobile development battle

People argue all the time about native vs web app development. Some say that the web will prevail, some say that native development isn't going anywhere any time soon.

I honestly don't care, neither regular users that have no idea how an app is developed. As long as it's good, everyone is happy.

However, staying out dry isn't fun, so I'll get wet by sharing my opinion: I do believe that the web has the winning ticket in this race (assuming there's one.) I don't know how this is going to play out, but I believe the web will win, just as it already did in the previous war (see desktop vs web.)

Too many things stacked against native development

Let's think for a second about all the advantages of developing a native application:

  1. Performance
  2. Better access to device's hardware capabilities
  3. Easier UX/UI alignment with the host operating system

Is there anything else that we don't have already with mobile web development? I'm sure I'm forgetting something (and I promise to add it as soon as you point it out to me), but there's not a whole lot more.

Now let's see my (probably heavily-biased) list of disadvantages:

  1. You have to build your application (separate code base) for every specific platform you want to target. (Sure there are ways to build-once / run-everywhere, but we all know they always leave you lagging behind.)

  2. Every day the average application size increases dramatically (way faster than the average connection speed.) Having to download 20MB for a relatively trivial application is a huge barrier for user adoption.

  3. By developing a native app you are getting in bed with very powerful companies (Apple, Google, Microsoft, ...) that can change the rules any time they please.

  4. These companies dictate what you can and can't do (specially Apple with the App Store's policies and the absurd way of enforcing them.) Some people see this as an advantage to keep certain quality standards, but I can't stop thinking about all the noxious effects that developers get as a byproduct.

  5. Developers have to pay for the privilege of developing applications for native platforms (at least for iOS and Android you have, not sure about the rest.) This is just ridiculous considering that developing for the web is absolutely free.

  6. You have to pay a 30% cut for every new user that buys your application. I understand you are paying for the privilege of using somebody's market, and that'd be great if you had any other viable options, but right now you don't, so paying 30% is all that's left.

  7. These markets hide your users from you. You can't maintain a decent business because you don't know who are the people that bought your application.

  8. Your target audience depends on the reach of each market. If there's a country that Google doesn't like, you can't sell your Android application there. Contrast this with the web only bound by a network signal.

  9. The pricing model for each market has become a race to the bottom where users expect the best quality for no more than $0.99. Hell, even at this price point is tough to make a business! (This has nothing to do with native app development, but I think we'd need to shake up the market pretty good in order to reset expectations and start fresh.)

The web is different. Is free. Is open. Is for everyone. Even more important, we all know how to work the web. We have gotten crazy good at it, and we ain't slowing down any time soon.

But mobile web applications suck

Let's go back to the advantages of native application development for a second, and pick up on the most glaring issue that I see with mobile web development today: performance.

60 frames per second in mobile web applications is still far from being available to everyone. Sure there are apps that don't need this, and that's great. There're developers skilled enough to get 60fps in their apps today, and that's also great. But nor every app neither every developer can say the same.

As a general rule, animations in mobile web applications are terrible. Native applications have set the bar too high, and despite all the performance advice you can find on the Internet, the mobile web is still years behind.

Along the same lines, if you want to access the camera, accelerometer, gyroscope, and any other hardware component of mobile devices, going native is the easiest way. I know you can do a lot today with HTML5, but we are far from being there yet.

But will this be forever?

We all know that browsers will get better (they have gotten inmensely better in the last 3 years alone.) I don't know whether the DOM will get faster or we'll find another way. There are no indications whatsoever that contradict this point, so I think it's a safe bet.

Will this abolish native applications? Of course not, but it will certainly increase the number of developers that will produce mobile web apps. More and more companies will be hard-pressed to justify the huge budgets necessary to target different platforms with different code bases, and will open the door to the web.

Even today, hybrid apps in the market are more prominent than ever before. How much time before less Swift/Java/Objective-C code is necessary compared to HTML/CSS/JavaScript?

(At my company, any mobile application we develop follows a hybrid approach. We usually build navigation and transitions in native code, but everything else is web.)

And of course, I might be totally wrong, but it's hard to bet for native development where there are so many things stacked against it.

So the web will be

Or at least I firmly believe so.

A lot of stuff will have to change, and even then native development will never stop. I think that with every ounce that the mobile web improves, the less developers will lock themselves in a proprietary mobile platform.

I won't. I don't see why other wouldn't follow.

And if you are reading this trying to make a decision for your next app, my advise is to forget about the controversy and develop the best experience that you possible can using the current tools at your disposition.

Everything else doesn't matter.

An introduction to data modeling using Google's Datastore

I've been there just like you.

I come from the relational world like probably everyone who's been doing software for the last 5 years or so. In 2012 NoSQL databases were already a thing, and I had an opportunity to work with Google's Datastore, so I googled the documentation and started from the beginning.

Holy Molly!

A couple of paragraphs in and I realized that the Datastore is a different beast. Every person I've talked to remembers having a hard time properly understanding all the concepts, and on top of that, the existing information on the Internet is scarce and spread all over the place.

After going through all of it, I wanted something for dummies and lazybutts. For people with no time to read over and over the same paragraph and make sense out of it. For people like me, basically.

So I've organized this post in the following sections. Feel free to skip to the appropriate place whenever you want, but I greatly recommend to read the whole thing from the beginning, at least the first time:

Entities

An entity is an object in the Datastore. Think of it as something similar to a tuple (also known as "row") in a relational world. An entity represents a particular element like the following book:

Programming Google App Engine. Dan Sanderson. Paperback. Oct 26, 2012

You can have another book entity:

Python for Google App Engine. Massimiliano Pippi. 184 pages.

And another one:

Google Compute Engine. Marc Cohen. Paperback. 246 pages.

Each one of these three entities represent a book and have properties that describe them.

Entity Kinds

To bring some organization to our entities we have Entity Kinds. These represent the type of your entities. In our example above the kind is book (of course, you can name it however you like.)

(Contrary to what most people tend to think, a kind is not comparable at all to a relational table. Please, don't go that way and start thinking more about objects and less about tables.)

The kind of an entity categorizes it for the purpose of queries. For example, we already have books, and we'll later talk about publishers. Each one of these represent a different entity (object) kind (type).

Properties

The properties of an entity are just like the regular fields you already know from the relational world (or "columns", if you wish.)

Programming Google App Engine. Dan Sanderson. Paperback. Oct 26, 2012

From the above entity, we can easily discover the following properties: title, author, cover, and publication date.

Python for Google App Engine. Massimiliano Pippi. 184 pages.

This one has title, author, and number of pages.

Google Compute Engine. Marc Cohen. Paperback. 246 pages.

The last entity has title, author, cover, and number of pages.

Notice how each entity has slightly different properties. This is a key concept from the Datastore: is schemaless, meaning each entity from the same kind can have any number of different properties.

Properties have a type, like String, Integer, Date, etc. (Python, Java). They can have single or multiple values (what!?), they can be indexed, sorted, and pretty much work like you already imagine.

Multi-valued properties

People usually freak out when they hear about this, but yes, you can have multi-valued properties in the Datastore.

So far we've only talked about properties with a single value, but what happens if there's another book in our collection written by more than one author?

In a relational world we'd probably need another table and a relationship. Here we just need to make author a multi-valued property (and maybe start using the plural authors instead):

Keys

So far we've been talking about four different book entities, but how can we uniquely identify each one of these?

Just like in the relational world, every entity in the Datastore will have a key that will identify the entity.

A numeric key will be auto-generated by the Datastore if one is not provided, or we can take on the responsibility and always specify a key when a new entity is created (either numeric or string).

For our book examples, let's assume our key is the isbn of the book:

(As you'll see later in this post, the composition of a key is a little bit more complicated than what you see above, but for this example, thinking of the key as the isbn of the book is good enough.)

Relationships

Let's say we also want to keep track of the publisher for each book. How about creating entities of a new kind named publisher?

We then can go back to each book, and add a reference property to the appropriate publisher (I'm omiting the rest of the fields for clarity):

isbn: 978-1449398262 
title: Programming Google App Engine 
publisher: oreilly
...

isbn: 978-1784398194 
title: Python for Google App Engine
publisher: packt
...

isbn: 978-1449360887 
title: Google Compute Engine
publisher: oreilly
...

isbn: 978-1118824825 
title: Google BigQuery Analytics
publisher: wiley
...

(I don't think "reference property" exists as a formal concept. Both Python and Java use different terminology to represent relationships, but for our purposes, a reference property is a concept similar to a foreign key in a relational database.)

You can also create a relationship from the publisher to the book using a multi-valued reference property books:

id: oreilly
name: O'Reilly Media
website: www.oreilly.com
books: 978-1449398262, 978-1449360887

id: packt
name: Packt Publishing
website: www.packtpub.com
books: 978-1784398194

id: wiley
name: Wiley
website: www.wiley.com
books: 978-1118824825

No matter how you decide to create the relationships, here is the full illustration with all our entities:

As you can see, so far the way to create relationships is very similar to the one you already know, with the addition of the multi-valued properties which makes things a little bit more interesting.

Consistency

At this point we have a total of 7 entities in our datastore: 4 book entities and 3 publisher entities. Do you know how the Datastore will physically store this information?

Google's Datastore is all about scaling. One way to accomplish this is by sharding the information across different distributed computers. To illustrate this point, we might end up with 1 of our books living in a Data Center located in Virginia, while its publisher might be stored in San Francisco.

What happens when we query for a book together with its publisher if they are stored in different computers? As you can imagine, the Datastore needs to find a way to replicate all the information across all Data Centers so we can access it from anywhere, but this process takes time.

Changing the publisher information in San Francisco means that we need to wait for a replication process to complete before the new data is available to query from Virginia.

This causes what we know as stale results: information that's not up-to-date when retrieved from the Datastore. This is probably one of the biggest challenges when using Google's Datastore.

Entity Groups

When I first read about having to deal with stale data, I hated it so much that I closed the page and didn't want to talk about it for a week.

You are probably feeling the same way. Specially because this is probably not a problem you have to deal with in the relational world.

Sure, there are times where stale information is not a huge deal, but there are cases when you can't absolutely afford to have this problem. How can you keep using the Datastore and forget about this glaring issue?

Well, luckily for us, there's another way: when designing the structure of your data, you can tell the Datastore what information is closely related and should be stored on the same place. This way, we make sure that when returned together (check ancestor queries), you'll never get stale data.

These clusters of entities are called "Entity Groups".

So going back to our example, books should be closely related to their publishers. Anytime you return a book, it's very likely that you'd want to also returns its publisher. This means that we should create an Entity Group with book and publisher.

An Entity Group will create a parent-child relationship between both entities:

Note how we ended up with three Entity Groups. Now, anytime that the Datastore decides to shard our entities, it will always keep together members belonging to the same Entity Group.

Ancestors

In Datastore lingo, the parent-child relationship to create Entity Groups is referred to as an ancestor relationship. The parent, parent's parent, and so on are ancestors, while the children, grandchildren, and so on, are descendants.

Any entity without a parent is called a root entity.

Why am I telling you this? Well, in order to refer to any entity in the Datastore, you need to do it through it's ancestor path:

[publisher:oreilly, book:978-1449398262]
[publisher:oreilly, book:978-1449360887]
[publisher:packt, book:978-1784398194]
[publisher:wiley, book:978-1118824825]

The ancestor path is also referred as the key of an entity (Now it's probably a good time to re-read the Keys section from earlier). For a root entity, the key will be just the entity's kind and identifier:

[publisher:wiley]

Write Throughoutput

The first time I read about the Datastore I quickly realized that Entity Groups are good to avoid returning stale data, so why not to create a big Entity Group with all the entities of the system? That will make all the queries 100% consistent, right?

Not so fast.

Entity Groups have the limitation of creating datastore contention when you try to update them too rapidly:

The datastore will queue concurrent requests to wait their turn. Requests waiting in the queue past the timeout period will throw a concurrency exception. If you're expecting to update a single entity or write to an entity group more than several times per second, it's best to re-work your design early-on to avoid possible contention once your application is deployed.

So although having Entity Groups are good for consistency, they are bad for write throughoutput. You have to find the proper balance for your own application.

What comes next?

Of course, modeling for the Datastore doesn't stop here. You've also got indexes (Java, Python), and have to deal with transactions (Java, Python), and queries (Java, Python), and all sort of interesting stuff.

But hopefully this post gave you an introduction to the main concepts of the Datastore and how these work in tandem to create your data model.

If you are interested to keep going, here are some pages I'd recommend:

Happy modeling!

After 30 minutes of a code review session

I had a code review session today. I was the one reviewing the code. I'm not going to say anything bad about it because I'm sure the person being reviewed (from now on John Doe) is going to read this article, but I wanted to write about what I felt after it.

It was great.

I now pretty much understand the code of something that I didn't write. It took 30 minutes to go over all of it. Enough time to get a general idea and being able to teach a stranger about it.

I had a ton of comments. I think good feedback (John, let me know if I'm mistaken). I think the code is better now thanks to those 30 minutes.

John Doe (dude, sorry I keep calling you this) has a better understanding of the code. He wrote it, but he discovered stuff hidden from him until today.

We made some business decisions. We discovered some areas where we needed more feedback. We were able to notice what's missing right now, what's working good, what can be improved. We added a bunch of stuff to our "refactoring" list.

30 minutes of our time together that will pay off in gold every day after today. Real good stuff.

Then I have to ask myself: Why in hell I'm not doing this more frequently?

(Maybe) a different way to become a better engineer

I'm not a Math guy. At all.

However, for some twisted reason I enjoy problems that fall right in the intersection of Math with Computer Science. If there's something that keeps me awake until I figure things out, this is it.

And some of these problems are not even practical or its application might not be immediately apparent, but I don't care much; I find them fun to solve, so I just do them.

Over the years, I believe these exercises have fundamentally changed the way I approach real life problems. They've sort of defined who I am as an engineer and provided meaning to my career.

You might be different. You might not care about this or might think that there are better ways to spend your time. However, I can't stop recommending these problems to anyone that is looking to become a better software developer.

This brings a different (fresh) perspective to my every day work.

(Sometimes I hear from people the dreaded "...and how is that going to help with my CSS?" stupid question, and the answer is "It will not". Specially because if you are stupid enough to think you can't learn more, your CSS should be in a pretty bad shape already.)

Just in case you are wondering how these problems look like, here is a fun one:

Given a set of N keys and an integer K, find the key smaller than 
exactly K of the N keys.

13 random thoughts for when building a timeline for a project

I wanted to put together some thoughts that I usually revisit every time I have to work on the timeline of a new project. The list below is not sorted at all, and definitively not curated, but it covers pretty much what I have in mind going through these exercises:

  1. During the first few weeks people need to settle in and workshop the foundation of the project. Don't put any deliverables during this time and make sure you add this buffer to the timeline.

  2. When starting the project look for quick victories. Something that builds confidence among team members.

  3. At the same time, try to prioritize work on the more risky features. You want to know as soon as possible whatever there's to know, so never postpone this type of work.

  4. Make sure to identify as many dependencies between features as possible. You don't want to schedule work first on feature "A" to later realize it depends on feature "B".

  5. The more people you add to the project, the more communication and overhead problems you'll have.

  6. Remember that more people working on the same thing doesn't necessarily cut the time in half (maybe it doesn't even cut any time at all). Related question: Can you have a baby in 4.5 months if you put two women on it?

  7. Past performance is a good indicator of future performance (some people call this "experience"). Try to find similarities with previous projects and make sure you schedule for "actual time" and not "expected time". (Actual time is the time it took your team to finish the previous project, and not the time you expected your team to finish it.)

  8. Keep in mind the skills of your team. This is a fundamental factor when determining the order of tasks to tackle and the overall timeline.

  9. I like to split the work in as many "releases" as possible. The earlier I can put something on the client's hands, the better. The number of releases will affect your overall timeline.

  10. Be careful when trying to accommodate "parallel work". It highly depends on the current team you have (skill-set) and not just in how many of them are available.

  11. If your team (or part of it) is sharing their time among multiple projects, take the time you have from them and cut it by 30%. That's how much waste you'll have to deal with.

  12. Make sure to measure your time. You'll use it later. (See number 7 above.)

  13. Give yourself enough buffer to breathe. I promise you are going to need it.

Always keep in mind this is an inaccurate exercise. The more you do it, the better you'll get but it will always be inaccurate no matter what.

The unremarkable career of (some) modern software developers

I graduated from college a little bit over 10 years ago, and I've been messing with computers since I was 14. This doesn't make me wise, but it certainly gives me a fair amount of experience to write one or two good tips for newcomers in the industry.

The world certainly moves fast, and faster goes technology. This we all know and are used to it, but certain things in Computer Science haven't changed and probably won't for a long time: the foundation of this career is not only well defined, but extremely important for anyone who ambitions to become good at it. Choose to ignore it and you'll be walking forever an unremarkable path.

I should've had started here

Let me start from the beginning what's already looking like a rant: back in the day when I was at school, all we had were hours and hours of Computer Science theory covering everything from wicked math classes, to data and file structures, to algorithms and everything in between. That was day and night, and it gave me the foundation I needed to understand how the hell I was supposed to program a computer.

That was the time when 1,024KB of RAM was a luxury reserved for a few. That was the time when everything had to be extremely optimized because fast wasn't a quality of the equipment. That was certainly another time, but today is different.

Or is it?

Fast forward a few years

Look around today; everything is so high-level. Nobody starts anymore from the same place I had to start back in the nineties; there's probably a library for that anyway. Programming languages have come a long way providing better tools, higher abstractions, and making our life easier.

And that's good.

Software developers spend every day less time concerning about tools and platform issues to focus on what really matters: innovation. From day one you get half the way walked for you (and maybe even more), so it's easier than ever to finish what you started, to create something remarkable.

And that's also good.

But somehow (and here is where my paranoia starts clouding my judge), we have forgotten what's behind all of this. We have forgotten that computers still don't understand anything past zeros and ones. We have forgotten that layer of complexity that makes the entire machinery work.

Do you really need all that?

Yes, you need all that.

Or maybe you'd like to be like Uncle Steve, who comes readily every time your car breaks just to tell you he can't do squat about it. Or like Aunty Mary, who knows every cold remedy but can't give you anything for after 3 straight fever days. In both cases you need to call the cavalry; you need the real solution to the problem.

So if you are fine settling with a band-aid role, be my guest. If you want to move past that and start wearing a real badge, you need all that.

Just like car mechanics start learning about bolts and nuts, and doctors go over every single bone and muscle in our body, software developers should start learning from the very basics of computer programming. You can't just jump straight to the finals and expect people to like you; you need every single bit of fundamentals if you want to be for the long run.

Still on the fence?

I honestly don't blame you. Today we've got Stack Overflow, and Google, and GitHub, and ten thousand developers creating new JavaScript libraries every single day. Why in hell would you like to start with comparing stacks with queues and linked lists?

The reason is because you need to understand how things work in order to create other things. Software development is about creating software (duh!), and despite so many attempts to fast-track this process, professional knowledge can't be challenged with templates and pre-defined blocks.

Like you can't expect to be accurate with a gun without understanding the basic physics governing a projectile in the air, you can't expect to Google your way out of every technical challenge you'll face in your career. A brand-new shinny library is not useful if it doesn't work out of the box and you can't figure out the reason, and contrary to popular belief, every single problem does not have a solution in Stack Overflow, so you need to be prepared for that.

I've seen; therefore I believe

For years I've been honing my skills in this "underworld" of Computer Science knowledge. Thanks to this I've gotten myself out of situations that would've taken others a ridiculous amount of time.

I've seen friends stuck with problems easily solved by a basic understanding of memory management. Or two people fighting over the way to go when one option was clearly a bad choice. Or the guy pulling his hair out because a couple hundred requests obliterated his entire system.

Every one of these cases became a problem because the fundamentals were ignored (or unknown). You can keep yourself afloat on high abstractions for a long time, but when the time comes, your only ticket out of drowning will be your ability to connect the dots and think through the problem.

Closing the full circle

Like great singers learn to play piano early on, software developers must learn their world from the inside. Here are just a few topics that will keep you in your toes and create a solid foundation to support your entire career:

  • Algorithm analysis
  • Data structures
  • File structures
  • Sorting and searching
  • Graph traversal
  • Dynamic programming

And that's just scratching the surface of what we all need. The content will never stop showing up at our door, begging to be learned. It's up to us to open ourselves to an experience that will shape our future like nothing else.

Choose carefully

If you are just starting out in this path, and siren songs asking you to keep your feet dry are resonating with you, think again: you may be barking up the wrong tree.

If you choose to be a professional software developer; if you want to be the person on everyone's speed dial; if you want to say “I've got this” and have everyone believe in you; don't go the easy way.

Choose to learn over anything else. Choose the pain, the tears, the nights and nights with your head stuck in a book. Choose to be somebody with a real and profound understanding of your field.

And there's only one way to do that.

Discipline does wonders for new TDD practitioners

Probably the most common mistake I see amongst people trying to do TDD is the lack of consistency following the TDD process. It is not about a specific thing they are doing wrong, but about reverting back to old habits any time things get complicated.

And believe me they will get complicated!

Heck, when you are starting, TDD is darn difficult! It's like teaching somebody who has spent all his life driving automatic cars, how to drive with a manual shift. Eventually things start making sense, but at the beginning what did you say is that third pedal for?

The thing with TDD is to stick with it. You know it will eventually click for you, but at first you have to be patience and need discipline to follow the process and don't deviate from it: Test, Code, Refactoring... Test, Code, Refactoring.

Lately I've been writing simplistic advice about TDD, but I do believe that the devil is in the details. TDD is not an obvious technique at first (I guess it might be for brand new developers), so it takes time to master and every single detail counts.

For now, military-style: follow through.

Lately I've been using more Python than Java and here is why

I've always considered myself a Java guy. I really liked C# back in the day when I actually used it, but I haven't for more than 3-4 years, so I can't say I'm a .NET guy anymore.

Anything serious I have to develop, I think Java first, but lately I've found myself changing the course a little bit1.

Python is so easy to use; the barrier to start is so low; what needs to be done to have a full working Python script is so little that it's just hard to justify not doing it in Python.

If I open my command line interface, type python and hit enter, I can start testing theories and trying out code right away without anything else. No IDE, no "New program...", no required main class, nothing.

The language itself is clean, easy to understand, and you can use any editor you have available. No Eclipse, no NetBeans, no IntelliJ, and not 5GB of Visual Studio for sure.

Like with Java, there are a bunch of people writing awesome (open source) libraries for Python. Like Java, you can run your Python code everywhere. Like Java, Python is fully supported in Google App Engine (and I'm in love with it!)

And like I mentioned before in a different post, it's not only me, which is really encouraging.

But of course, this doesn't mean I don't love Java. These two are both great languages and I'm not planning to ditch Java anytime soon. Python however is winning the lightweight title with me. More complicated stuff? We'll have to wait and see.

(If you are starting out in a development career, I seriously recommend you to look at Python. You'll love it and it will teach you all the fundamentals necessary to step up to more serious stuff later. And of course you can always buy this book, love Python forever, and never ever move on.)

--

1 For the last 4 serious projects I've coded I used Python three times and Java once (and Java just because it was an Android exercise for my Masters class.)