Some days you are tired

Some days you are tired
Maybe you are tired of all the work
You can’t keep up with, it all piles up
Of all the meetings and reports
That come relentlessly without end

Some days you are tired
Maybe you are tired of all the time
That you never have enough of
Of all the deadlines and targets
That you never meet but should’ve

Some days you are tired
Maybe you are tired of the world
And how it’s unfair and never learns
Of all the madness and insanity
And sometimes you want to watch it burn

Some days you are tired
Maybe you are tired of people
And all of their pressure and expectations
Of all their lies and inconsistencies
Or disappointments in their decisions

And on some other days
It’s more of the same

But also maybe you see a smile in a child’s eyes
Or maybe you run into a long-lost friend from years ago
Or maybe someone laughs at a stupid joke you said
Or maybe you see a stranger help another
Or maybe you find a new favorite place to eat
Or maybe you solve a problem tearing you up inside
Or maybe a familiar tune plays on the radio
Or maybe finally you’re no longer in the red
Or maybe good fortune comes to your brother
Or maybe you find some time alone to breathe

And then you remember
That it doesn’t always go this way
That there are also better days

And you say to yourself

“Maybe tomorrow, I will not be so tired”

The Secrets to Perfect Estimates

Estimation is hard. Estimation has long been the bane of many software developers and software development projects. But there are two secret ways to be able to produce perfect estimates for software development work all the time! One is dependent on talent, and the other is dependent on technology

  1. Psychic precognition, i.e. be able to predict the future
  2. Have a time machine, so you can go back in time and tell yourself how long the work would have taken

Such precognition is necessary to have perfect estimates because of all the unknowns present at the start of a software project. Unknowns include imperfect requirements or design, unknown user needs, future changes that may happen during the course of the project, unforeseen technical challenges, and so on

In the absence of the ability to break the laws of causality however, the only time we can have perfect estimates is at the end of the project! Before that, we are sadly restricted to imperfect estimates. In reality, the best estimates will still always be an educated guess

Okay, for real now: there are two ways to handle the risks associated with poor estimates, and for most projects both will be necessary.

The first is to plan around inaccurate estimates. This means that your planning acknowledges that estimates will often be inaccurate and building a sufficient amount of loose or buffer time in your scheduling to accommodate any variance. Less enlightened managers and executives will hate this, especially anyone who comes from a world like manufacturing where the rate of production is extremely well-known and predictable. They will view any kind of schedule buffer as some sort of justification for slacking off. As a software developer, you will have to deal with these sorts of people throughout your career. It will be part of your job to work with them to manage the schedule, manage their expectations, and get them to understand that while the software development process is in many ways an engineering process, there are still numerous uncertainties that will not resolve themselves until you find the right arrangement of code

The second is to learn how to make better estimates. “Better” here doesn’t necessarily mean “more accurate”, but rather “less likely to be very far off”. There are numerous books already written on this subject (I recommend Steve McConnell’s Software Estimation: Demystifying the Black Art if you can afford it), but basically the advice can always be summed up as: use data from previous experiences to predict the likely effort needed for future tasks.

It’s usually best if you are able to draw upon your own experiences since often the actual amount of work needed will be specific to the developer’s experience, for example: “It took me N days to do a similar task before, so I think I can do it in N+2 days. The other guy doesn’t have experience with this stack, so I guess that he can do it in N+7 days”

In the absence of your own direct experience, you can look to either expert opinion (consult someone else who has more experience with the subject and ask him for an estimate, and compensate accordingly for any difference in skill/knowledge) or use some sort of numerical model. Such models will typically rely on some sort of metric to measure the size of the system being developed, then use historical data to predict how much effort a system of this size would require. An example of such models is Function Point Analysis. Different models will tend to have their own advantages and disadvantages – for example, I’ve found from personal experience that Function Point Analysis can be greatly inaccurate if there is a lot of technical risk in the proposed system – so it would still be wise to make planning adjustments accordingly and not just follow the model blindly

One last thing that software developers need to note with regard to estimates: if you know that you have made a good estimate, that it is already as accurate as it could possibly be: do not allow anyone to pressure you into providing a different estimate. Giving in to such pressure does no one any good: it only puts the project at increased risk, and it puts your own credibility into question. Such pressure often comes from management or clients as a result of schedules or deadlines, something that I will talk about in a later post.

In the end though, all the best practices will be for naught unless you understand the fundamental truth: there is always a chance for estimates to be inaccurate. No amount of planning or best practices can completely mitigate that risk – unless of course you have either a precognitive crystal ball or time machine!

The Things We Learn In School

When you’re young and in school memorizing math formulas or history dates or whatnot, all of it seems so silly and you wonder if you’re really going to be using all of this knowledge in real life. However, the intent of a general education program isn’t specifically to give you knowledge that will be useful to you in the future (although it may turn out to be so)

The stuff school teaches you – literature, mathematics, art, history, science, and so on – are intended to give you a broad enough base from which you can freely choose the direction you want to go in life. This means that as you specialize, many of these subjects may become “irrelevant” to you, but having this broad base of knowledge gives you a better foundation in life. Knowledge from unrelated fields can often give useful insight into your own specialized field

That being said, the most useful stuff you learn from school isn’t the stuff that’s in the lectures or in the textbooks. School is supposed to teach you about more than formulas and history dates too. But it’s a problem that most of the time, formal education doesn’t deliver the lessons well enough. Math shouldn’t be about memorizing formulas or equations, but about developing analytical and problem solving skills. History should be about appreciating how changes affect people and societies, not about memorizing dates. Science should be about appreciating how nature works and developing scientific curiosity. And so on. But because these things are difficult to teach and test for, formal education usually focuses on facts and figures and formulas and all these things that appear in exams. It’s up to the student (or his mentors encourage him) to apply himself further

There are still many more holes in formal education. There are memes about how you learn not so useful stuff like “mitochondria is the powerhouse of the cell” instead of real-world useful things like how to manage your finance or how to do your taxes. And for sure we need more of those practical things taught to students.

But the most important things you learn from school are in the methods of learning and working well with others. School teaches how to apply yourself, how to study and pick up new material, how to listen to other people, how to determine which knowledge is useful to learn, how to discern truth from fiction, how to work within a set of rules, how to manage your time, how to deal with schedules and deadlines, how to work well with other people, how to deal with difficult people, and so on. In short, the most important lessons school teaches you are about how to deal with the real world

We Must Speak

If you follow me on Facebook or Twitter, you’ll know I have a tendency to be pretty vocal about any problems I have with our country’s erstwhile leadership. But for the most part I’ve restricted it to those channels and have tried to avoid posting about current events in the country on this blog (outside of my personal choices for the election), but I feel that now more than ever those of us who can speak out have a responsibility to do so whenever we can, for several reasons

Village Idiot Savant says:

“Third, write. But don’t write as you would for the consumption of social media, write instead to keep a record of these times. Write in long form, write reflections, write your frustrations, write with big words, write even if it appears you are rambling. Write with Art and with Irony. Because we will eventually emerge from this period of madness, hopefully to a season of sanity, and we will need to look back and remember, and if needed, to indict. Write because it will someday be history.”

That last part resonated with me. “Write because it will someday be history.” It reminds me of where we are currently with the Marcos legacy, with an entire generation having been brainwashed to believe that Marcos was actually a hero and a positive influence on this country, all because in the intervening years since the EDSA revolution we (and by we I mean we the people, not just the government) grew complacent and believed that exile was sufficient and that we would not have to worry again about such a dark time in our society to come back and haunt us again

And yet here we are again on a road, perhaps even a slippery slope, towards a dark future. Marcos is again being glorified, and the state is once again extending its reach with the similar excuse of “peace and order”. We do not yet know where this path ultimately leads, perhaps it won’t be the darkness many of us can foresee, perhaps we as a society are able to turn away from the brink before it is too late. There are those who believe it is already too late, that we are already in the darkest timeline

Even if our country falls under a shroud of darkness, like the darkness of Martial Law it will also eventually pass and hopefully we emerge on the other side stronger and wiser as a country. In the hopes of that light beyond the darkness, we must write. We must take our voices and speak out against what ills we see. It often feels futile, with many of our countrymen already having surrendered their wills to the violence. Many are unwilling to listen, many treat the current leadership as if they are infallible demigods who could do no wrong. Maybe there is really no one listening and you are but a lone voice crying in the wilderness. It is not for them that we need to write, but for those of us who still hope for a better future. And for those in the future to recognize and learn from the mistakes of our time

We must write and speak, while we still can. We don’t know whether we will still be able to speak up tomorrow.

In addition, we should write to spite those who would silence us for our opposition. For many of the administration’s supporters, anyone who speaks out is an open target for harassment and accusations most vile, as one of Rappler’s correspondents recently found out:

I can appreciate those of my friends who limit themselves to “like”s on the posts of those who speak up, or who limit their support to private discussions. Not everyone has the liberty to speak up. Not everyone can afford to sacrifice time nor ego to the possibility of a horde of online trolls pouncing on you. Not everyone can afford to be stressed out over this. Not everyone has the temperament to be willing to offend other people or risk losing friendships. All the more reason for those of us who are able to speak up to keep on going and to persist in the face of overwhelming ignorance and hypocrisy. The ones who cannot afford to speak, we speak for them too

One of the reasons I didn’t write about this too much on this blog is that I didn’t want this channel to become about politics. But it feels like so much more than just politics now. Despite what some fanatics may have you believe, we do not voice opposition simply because we believe in another camp or because we want to destroy the current administration. We voice opposition because we want the best for our country, and we believe that these issues – the continuing demonization of human rights and due process, encouragement of a culture of killing and violence, intellectual dishonesty and willful ignorance, and so on – are issues worth raising up and discussing

I am sure I have friends and family who are tired of me bringing up such subjects. At least one person has unfriended me already without explanation, although circumstances dictate it was about “politics”. For my friends and family, I apologize. If you are tired of me speaking up, please trust that I am tired too

Programming is Finding the Right Arrangement of Code

I like to say that software development is a challenging career because no two projects are ever the same and there are always new challenges to face and new concepts to learn, but the truth of the matter is a bit more complex.

Writing software is about breaking down large problems into a series of very small technical problems for which we already have solutions. Examples of small enough technical problems include list sorting, comparison, arithmetic operations, path traversal, string concatenation, returning a string as an HTTP response, rendering text to the screen, retrieving submitted parameters from an HTTP request, and so on. Any given non-trivial software project will be broken down into thousands, possibly hundreds of thousands of such small tasks, some occurring more often under different contexts.

The job of the software developer designed to implement such a program or some part of a program is to identify all those tiny tasks and the order in which they need to be done, then actually do it and put it all together in a way that satisfies the software’s requirements. Finding out the proper arrangement of tasks is a form of design in and of itself, separate from the design of the software requirements. This is why many programmers will tell you that coding itself is both design and implementation – the coder still has to make numerous small decisions, rearranging code and tasks until he finds the correct arrangement that works to satisfy your needs.

Invariably, practically all of these tiny tasks are either trivial to implement (based on knowledge the programmer already has), or have already been implemented somewhere else by some other programmer. This is why Q&A sites such as Stack Overflow are very useful for the modern programmer – you simply dip your pool into the communal knowledge of the programming community and most of the time the programmers who have solved the same problem before will tell you how they did it.

“Practically all” means in the rare instance, you will still encounter problems that as far as you can tell have yet to be solved by anyone else in the world. I am unsure if there is anything quite as depressing to the programmer as finally finding a single Google hit about that one problem he was unable to solve only to find that it was a link to his own unanswered Stack Overflow question from months before.

Often this happens when you are doing something or some combination of things so obscure no one else has tried it before, or when you are legitimately blazing new ground. It largely depends on the field you are working in – if you are using proven frameworks to build your 10th web application, most likely 999 out of every 1,000 problems you have are already solved. On the other hand, if you were maybe writing drivers for a new piece of hardware, or maybe writing a new framework to be used at the same time as the first application using it, that number shoots up considerably.

What to do when faced with such a situation where all the sources you consult – mentors, experts, textbooks, the internet, and so on – are unable to help you solve the problem and it stops you from moving forward? Well, if you can sense that trying to solve the problem on your own or brute forcing it in some manner may waste a lot of time that you can’t afford, you should remember what I said above: Writing software is about breaking down large problems into a series of very small technical problems for which we already have solutions. This means your first choice should be to check first if there is an alternative arrangement of tasks for which that particular problem could be avoided (that is, “re-design your code to work around the problem”). You shouldn’t box yourself into a particular sequence of steps, be willing to “think outside the box” to look for other solutions that while not immediately obvious, may be more feasible (i.e. “already solved”)

This method of iterating the arrangements of parts until the software works might seem a bit clunky, but I’ve found it useful to think in this manner – it makes even the impossible problems seem feasible. Now, if only problems with humans could be solved just be rearranging things…

Internet History

No, not that kind of history, don’t worry.

Twenty-five years ago this month, the first website went up on the world wide web. That was 1991. It took a few years for the Philippines to catch on, the first internet connection in the country was only set up in 1994.

My personal experience with the internet came a bit later, during our freshman year in University, sometime in the schoolyear 1995-1996. Around that time a couple of friends and I would walk out to this computer shop along Katipunan avenue that had internet access. Computer shops weren’t prolific back then, and most of them offered only document editing and printing services. They didn’t even have LAN gaming back then, as DOOM had only come out the year before and Starcraft was just a gleam in Blizzard’s eye. This particular computer shop we trekked to had 2-3 terminals with internet access, which at that time we mostly used to browse anime-related websites and fanfiction (RIP Anime Web Turnpike)

Internet usage grew quickly in the succeeding years. A couple of friends got internet connections first. One of them lived near the University so a bunch of us happened to hang out there often, not just for internet access but also to read manga and watch anime. We jokingly referred to his house as “the Entertainment Capital of UP Village”

I forget when we got our own internet connection at home. I don’t even remember the provider we used. We stuck with one of the monthly plans for a while, but also went through a period of trying out prepaid internet access plans (RIP ISP Bonanza) and sometimes even hacking a free email service to also give me internet access (RIP Edsamail). It was the days of dial-up modems and beeping sounds, when piracy consisted of arcane commands issued in dark IRC channels. (The first time I got pirated music wasn’t off the internet however – for some reason I had gotten an MP3 of Oasis’ Wonder Wall on floppy disks. Yes, multiple disks).

Aside from the piracy and the fanfiction, the internet was a treasure trove of information. I quickly learned the usual web development skills – HTML and CSS were relatively easy, and I had a geocities website set up back in the day, a strange green-text-on-black-background kind of thing (I was never particularly good at web design). My email address for most of the university years was a Yahoo one (RIP Yahoo 2016), which I often used to join discussion groups on various geeky topics like video games and anime and what not – these days we have reddit for that.

Today, internet in the Philippines has come a long way and is a big part of daily life for most people. There’s still a lot of improvement to go – broadband here is still very expensive and very slow compared to other countries and there is no real competition yet, something hopefully to be solved soon.

What was your first encounter with the internet?

Review: Stranger Things

So, Stranger Things

It’s true, it’s great. I thought it might be overhyped, but it’s not. And I can see why people find it hard to explain without spoiling things.

It’s about strange things happening in a small town. Creepy things. It’s a mystery. It’s suspense. It’s not a jump-scare sort of thing if you’re not into that. Well, there’s maybe a little bit of jump scares. The best description I’d say it’s about as scary as an X-Files or Doctor Who episode. So if that’s not too scary for you, you’ll be fine

It’s about a child who goes missing in a small town (not a spoiler) and the succeeding events. It’s about the mother searching for her son. It’s about a group of kids trying to solve a mystery. It’s about a small-town police chief in over his head. It’s about the 80s. It’s about kids in the 80s, music in the 80s, school in the 80s, small American towns in the 80s. It’s about outcasts and bullies and first times and trying to fit in and how they all deal with these stranger things

It’s like Stephen King wrote an episode of X-Files and it was directed by Stephen Spielberg starring the cast of Stand By Me. The acting is great too, especially the kids

Maybe minor spoilers follow

It’s kind of told in that weird True Detective way, with perspectives jumping around a lot among the ensemble cast. Past and present scenes are interspersed with only context to rely on

It keeps you hooked. I wanted to watch only a couple of episodes at first but ended up awake past three AM at episode six. I finished it the net morning

I love how the mystery unfolds to different parties and separately they uncover parts of it and they all come together in the end to force a resolution. I love how the characters overcome their horror-movie tropes. I love all the 80s references and the geeky references

I was satisfied with how it ended and all came together. I’m not sure what to expect for a second season though

Living With Development Standards

I was originally going to write a post about the problems development teams face as they get larger, but the section on development standards was long enough by itself so here we are.

Having some sort of development standard in a project development team becomes a lot more important as project size goes up (for obvious reasons). There are different kinds of standards to consider, but generally I break them down into design standards and coding standards. Standards are important not only to ensure consistency among the development team, but to ease transitions both for new team members coming into the project late, or team members moving laterally to other positions or sub-teams within the same project

Design standards are generally UI and functionality related. UI standards can refer to what kind of controls are preferred to be used, where screen elements are expected to be placed, how error messages are presented, that sort of thing.

Functionality standards are more to establish similar user expectations as to how the program works. When I click Save, can I continue editing the same record or does it send me back to a listing screen? When I delete a record, is it reversible or will the system warn me that the deletion is permanent? When I enter a search criteria, is it case-sensitive? Having similar behavior throughout the system makes it more intuitive for users to navigate large, complex systems.

Coding standards refer to standards that developers follow, and will typically encompass:

  • Naming conventions. Applicable to variables, files, database tables and fields, and so on. This can be difficult to enforce, as some part of it is subjective. But it’s important that the same things are always named the same way in different parts of the code. It can be more difficult in larger development teams that are split among different domains. A simple example is one sub-team might name their reference number database field REF_NO while another sub-team sues REF_NUM. At the very least having consistent naming will make it more intuitive for developers reaching across different domains to link fields to each other
  • Speaking of database fields, another thing to consider is data types and field length. It can be unpleasant to find out later on in the development process that one sub-team has used VARCHAR(35) for all their email fields while another one has used VARCHAR(70). Or maybe some tables have a reference number field as an integer while others have it as a string. Such inconsistencies can lead to integration problems later on
  • Code formatting. Generally covers indentation, bracket placement, spacing, etc. This is generally only an aesthetic choice, but may cause religious wars with some developer groups (“tabs vs spaces!!!”), but generally someone should just choose a standard and the developers follow it. Luckily, modern IDEs support autoformatting options that can be exported and distributed for all the developers to use, eliminating most such issues. If not enforced in this manner, it may create some issues though if different developers have different autoformat settings. For example, in one project I was on a certain developer had an autoformat setting to automatically declare as final any function parameters in Java files. This was an ok practice on its own, but he was the only one with that setting, so when he would make a change to a Java file written by someone else, those “final” keywords would be added automatically. It wasn’t an issue most of the time, but when I had to check changes in source control, it would often be troublesome trying to isolate what change he had made in large files since there were all these other irrelevant changes found by the diff. Enforcing a standard formatting eliminates such issues
  • File organisation – a software project will typically have hundreds if not thousands of different files of varying types. Some sort of scheme is necessary for developers to follow to ensure order. For example in a web development project, HTML templates should be placed in a specific folder, CSS files in a different folder, JavaScript files in a different folder, and so on. Often there will also be subfolders either by domain or functionality
  • Implementation standards – typically in my projects I’ve found a need to standardize the approach for similar types of functions. For example, all search screens should be implemented a certain way, etc. Can be enforced by either language constructs or code templates
  • Best practices – many organisations will have their own set of coding best practices designed to help avoid common problems
  • Other, program-specific standards. For example, your Java project may require that all classes of a certain type use a particular form of constructor. If you’re lucky, such standards can be enforced using language constructs such as interfaces, but that is not always the case

Ideally, all of the above standards are codified in some sort of standards document that the development team can reference on a regular basis. But due to the constantly evolving nature of software projects, most teams will find that the typical documentation problems arise for standards documentation:

  1. You often won’t know ahead of time all the kinds of standards you need. Often later in the project new situations will arise that need standards but either the team may not recognize it or will not have time to document
  2. Standards will often become out of date or irrelevant. Updating these documents will often not be a priority as schedule pressure mounts
  3. As the problems from 1 and 2 mount up, more and more knowledge that should be codified as standards instead become unwritten tribal wisdom that can only be learned by experience or consultation with the experts
  4. After a certain point, adding new things to the standards document becomes counter-productive. When there are too many standards to follow, it becomes a challenge to even be aware of them all much less enforce them

It is a difficult problem to solve, and probably impossible to solve completely. I believe we will have to live with all of the problems above to some degree. There are a few ways to mitigate the effects:

  • Automate whenever possible. There are now many modern tools to automate checking for code formatting issues and so on
  • Prepare standards documents/bibles for the most common cases
  • Prepare step-by-step implementation guides and code templates for commonly-done tasks/functions. (Examples: “How to implement search screens”, “How to integrate our workflow library”, etc) – guides and templates don’t guarantee adherence, but they should help reduce incidents of standards not being followed
  • Mentoring for new team members or those transitioning to new roles
  • Recognize and accept that as project teams get larger, there will be a greater overhead spent on ensuring standards are followed and that the team is aware of them

All of the above are my own thoughts arising from my own project experience. I haven’t read much outside literature on this subject or other approaches within the industry at large, so I’d be happy to get more information on this matter

Thirty Eight

Thirty eight lessons I’ve learned through the years, in no particular order:

  1. Do not be beguiled by pretty things; not all that glitters is gold
  2. Remain true to yourself in the face of adversity
  3. You can’t help people who aren’t willing to change
  4. People will believe what they want to believe
  5. You don’t have to do what everybody else does
  6. Happiness often comes from small things
  7. Be thankful for what you have and appreciate the people who are there for you
  8. Other people think about you a lot less than you think
  9. Time you enjoy wasting isn’t wasted time
  10. Spend some time alone with your thoughts regularly; solitude has its benefits
  11. In most situations, a balanced approach will serve you well. Extreme or fanatical views will rarely be good
  12. Occasionally try again things you earlier dismissed, in case that they have improved or your own tastes have changed
  13. When in doubt and things are urgent, pick one option randomly and go.
  14. Don’t be afraid to speak your mind
  15. Life is too short to waste time on things that you don’t enjoy or don’t help you grow or people who don’t appreciate you
  16. It’s never too late to be who you were meant to be
  17. If it’s important to you, keep track of it
  18. The world is too amazing to be bored
  19. It’s okay to be weird and/or random every so often
  20. Life has no meaning except what meaning you give it
  21. All things, whether good or bad, shall eventually pass. Enjoy the good while it lasts, persist through the bad until you make it through
  22. Avoid doing or saying things in anger or hatred
  23. Things change and people change, sometimes for reasons we can’t ever explain. Learn to roll with life’s punches
  24. The world is filled with people who are terrible, cruel, or manipulative. That doesn’t mean there aren’t good people out there and that doesn’t mean you should mistrust everybody. “Do not let the world make you hard”
  25. Don’t worry too much about things that you can’t understand or can’t change. Focus only on things you can affect and that matter to you
  26. Quality is nice, but quantity often works too. Many failed or mediocre attempts will eventually converge towards a quality success
  27. Learn to accept when things need to end. Let go or be dragged
  28. Sometimes you just need the courage to power through the difficult parts
  29. For many things, the best way to improve is with time and practice and effort
  30. Learn from the past, look to the the future, but live in the present
  31. Life isn’t fair. Just because you’ve done all the right things doesn’t mean you’ll get what you want, even if you feel like you deserve it (the converse is also true – even if you do all the wrong things you won’t necessarily get punished for it)
  32. Strive to be fair and honest with people you deal with. Give credit where credit is due
  33. In order to learn, teach. In order to lead, follow
  34. When you are ahead, strive for stability and balance. When you are behind, be willing to gamble
  35. Always keep learning and improving. Every day, try to improve yourself or learn something new
  36. Every once in a while, expand your horizons with new things or different points of view
  37. Words are wind. Reinforce your words with deeds
  38. Age is merely a state of mind

Pros and Cons of a Career in Programming


  • It is a very rewarding career financially. Software development often ranks in the top 10 highest-earning careers in most countries
  • There is a lot of scope – you could be developing web applications, mobile applications, embedded applications, client-side, server-side, data analysis, artificial intelligence, games, etc
  • It is very difficult to be bored. You can always automate away the boring stuff. Different projects always present different challenges. The field is evolving rapidly so there are always new things to learn.
  • It is both a creative endeavor and a technical endeavor
  • Lots of opportunities for remote work/working from home, if that is your thing
  • You get to work with a lot of smart people
  • Access to a worldwide community of people who think in a similar manner. Most beginner and intermediate problems easily solved through the internet
  • Generally, working in a programming company is more likely to be a meritocracy – people with better technical skill are more likely to be valued
  • There are a lot of opportunities – if you are unhappy where you are, you can easily look for another opportunity


  • It is not for everybody. It requires a certain type of thinking that you may or may not be used to. Typically the field needs the ability to think logically and incrementally (step-by-step through how things happen) and to understand how multiple components work and interact together. More advanced challenges will also require significant out of the box thinking
  • After some time, you will tend to interpret things more literally. This is a side effect of working with computer programs that may affect your social interactions
  • Many people outside of the field will often find it difficult to understand the amount of work that goes into a computer program. This can lead to difficult conversations, especially with clients
  • Your nonprogrammer friends and relatives will often ask you for technical help, even though you know nothing about their printer and will most likely just google the information
  • Typically, the industry is very bad at estimation and scheduling, leading to a lot of overtime and the corresponding stress
  • The field is evolving rapidly, so there is often a need for a career programmer to self-educate to remain up-to-date with current trends
  • Encountering a highly difficult problem that no one else has been able to solve may drive you insane

(Previously published as an answer on Quora)