Posted on 2026-01-12
This post is a short description of what my career as a software developer has been, followed by a few observations and recommendations for those starting a career in software development.
I wrote this piece based solely on my experience as a software developer and my recollection of thirty years in the field, it is therefore a very selective story (that's how memories work) and it is also just one data point. I hope some of the things that I have experienced and learned can help others starting their journey in software development because one of the things that I have noticed is that although a lot has changed throughout my career a lot has also stayed the same.
If I were to split my career into four buckets they would look more or less like this:
I went to college in 1991 and graduated with a Bachelor of Science in Computer Science from the Instituto Tecnológico de Colima (México) in 1996. I was lucky to work on programming gigs all throughout my college years and got a full time job as a software developer immediately after graduation.
One of the things that I experienced back then was that the tools and technologies that I was learning in college were quite different from the tools and technologies that I was using in the jobs available to me. For example, at school I was learning about VAX Computers, COBOL, Db2, and Assembler but the jobs that I was getting were using databases like dBase, programming in Pascal, and the computers were running DOS or Windows. These two worlds couldn't be more different from each other.
I think this disconnect between what's being taught at school versus what's being used in practice is also common these days. But as I would elaborate later on this post, in the long run that's not nearly as significant as it might seem.
In the late 90s and early 2000s I became a consultant and started working on client-server applications. These applications were very different in architecture to the ones that I had worked on before that ran on a single machine. My work was with the Microsoft stack and therefore those applications were written with Visual FoxPro, Visual Basic, or C# and used SQL Server as the database.
The shift to client-server applications was a big shift from my first gigs and from what I have learned in school, but the fact that we learned about networks during college became really handy when working and designing these kind of applications. The size of the database in client-server applications was also much larger than databases in single-user applications and having foundational knowledge on algorithms, concurrency, and how relational databases work was helpful.
Being a consultant had the advantage that I got to work on many different projects for different domains like insurance, banking, and construction but it had the disadvantage that I was never long enough on a project to see how the decisions and implementations that I made worked out in the long run.
I was a late comer to web development, but around 2005 I started to get more and more involved with it and eventually it became pretty much all I did. I was still heavily involved in the Microsoft stack and therefore the web applications that I worked on were written in Visual Basic.NET and C# using ASP.NET and SQL Server.
I also stopped working as a consultant and became involved in projects that were longer term. This allowed me to work on applications that were more complex, some of them because the kind of rules and logic that they had to implement (e.g. to process bankruptcy claims or tax preparation) and others because the amount of data they processed or the amount of concurrent traffic they had to sustain.
Around this time I also got interested in software development processes (e.g. Agile and Scrum) and that led me to also focus more and more on the people in the team and the way we work together.
Around 2011 I started to get curious about what software development outside the Microsoft stack looked like1. After a few years playing around with Ruby in my spare time, in 2014 I took a full time job as a Ruby developer. This job was at the Penn State University Library and I took it because they were working on Ruby and that's what I was interested in doing at that time. Little did I know that this job was going to change my career trajectory in a big way.
After working at Penn State for a couple of years my next job was also at an academic library (Brown University) using Ruby. Although I was still interested in Ruby this was the first time that I picked my next job based on the institution and the kind of projects they were working on rather than because of their technology stack. Certainly my knowledge of Ruby helped me get the job, but my interests in libraries rather than the technology is what drove my decision.
Several years later I changed jobs again to my current employer (Princeton University) and, like with Brown, my goal was to work in interesting and challenging projects in academic libraries more than to stay with a particular technology stack. My work at Princeton uses Ruby but the Ruby part is not nearly as important to me as it was when I first started working in libraries 10 years ago.
After working for more than 10 years in academic libraries I feel like I have a good enough understanding of the library field that allows me to contribute at a different level and I am enjoying this stage of my career. I am still a software developer and write a lot of code as part of my job, but I am more interested in librarianship, data repositories, the stakeholders of cultural heritage institutions, and the system as a whole rather than just the software and technology components.
Although the career trajectory that I just described might look like a logical progression, the journey was anything but straightforward. There were many technologies, paradigms, and tools that I experimented with along the way that went nowhere. Some of the technologies that I used are not around anymore, products and tools have come and go, and programming paradigms have shifted2.
But all those steps along the way have shaped the way I see software development today and have enriched my understanding of the field. Below are a few observations that I think are worth highlighting, particularly for those starting their journey in software development.
There is always something new to learn in this field. If you enjoy learning new things this is a very attractive field.
As you learn new things, particularly new programing languages and programming paradigms try to learn them as they are meant to be used. For example, if you are a Java developer learning Ruby, try to learn and use Ruby as a Ruby developer would use it, don't try to use it as you would use Java. The same is true if you are a Ruby developer learning Java, learn how to use it with the mindset of a Java developer. This is important because using the new tool as it is meant to be used opens up to different ways of thinking of programming and allows you to leverage the benefits of the new tool (as opposed to continuously fight with the tool because you are using it in a way that it was not designed for).
The same is true if you are trying to learn functional programming and you are coming from an object-oriented background, embrace each approach's core principles (which might be counterintuitive at the beginning) so you get to experience them well.
I have found that writing blog posts and presenting at conferences are great ways to learn new things because presenting the work to others forces you to dig deep and make sure that you understand the technology well. Plus it gives you great exposure to other people with similar interests.
As you begin your journey you might feel that you are already behind and it's too late to learn something. Don't let that discourage you. The initial learning takes a bit of time, but it gets easier to learn new things as you go (since you'll have a broader foundation) and you'll catch up rather quickly as time goes on.
As I mentioned earlier, the tools that I learned while I was at school are mostly obsolete by now, but the theory and principles that I learned still apply. The knowledge about networks, databases, algorithms, operating systems, graph theory, and such are still at the core of the tools that I use today (30 years later) and behind the design decisions of the systems that I build and work with. What I learned during my college years was in the long term well worth it.
In fact a lot of the tools and techniques that I used early on my career (which were already different from the ones I used in college) are also gone by now. But working with them allowed me to grow as a developer and to learn new ways of thinking about software. All of these steps, even the ones in the wrong direction, enriched my career.
We, as developers, tend to focus a lot on our tools and it pays to know them well. Employers and our peers will value if we are knowledgeable about the latest version of Ruby, Java, or PostgreSQL. My advise to newcomers is to become very good at the tools that you use and keep up to date with them, but at the same time, stay humble and be willing to ditch them and shift gears when you feel the time has come. Don't bash other tools and paradigms just because you don't use them, as your career evolves you might find yourself needing and wanting to learn other tools and paradigms.
A lot of us get into programming because we like problem solving and there is a lot of that in our day to day job as software developers. But be aware that software development at large is about solving problems with others, with unclear and changing requirements, and our solutions will require maintenance (i.e. we rarely solve a problem and are done with it.)
The group of people that you will work with will vary throughout your career, in some projects you'll work with other developers, in others you might work with other IT related people (even if not developers per-se), and in others you might work with stakeholders that are no in IT related positions. Working well with others and being able to communicate with people that have different technical knowledge is a great asset and will allow you to see the problems from different angles. A lot of times the problem cannot be solved with just code, and knowing how to navigate through the domain will give you better insight on the problem and possible solutions.
Remember that technology and software development are political. It's common for people to think at algorithms are "pure and free of biases" but our tools and the solutions we build are used and deployed in ways that tend to amplify biases. You might think that a sorting algorithm has no biases (how could it have biases, right?), but as soon as you deploy a system that uses such algorithm to decide who receives something and who does not, your program is not pure and free of biases as you might thought3.
At one point in your career you will screw up something big: you might take down a server accidentally, delete the wrong file from system, delete the wrong records in a database, you name it. It will happen.
First of all, please know that this kind of experience happens to all of us. Given enough time we will do something like this at one point or another. Most likely it will happen in the early years of your career since that's when you are most inexperienced, but it also happens to experienced developers.
Secondly, do not let an incident like this discourage from the field. Remember that you are new and there is a lot going on on a given system. Good systems have checks to prevent single users from taking them down. And yet, we still manage to find places where the checks are not good enough or missing entirely.
Hopefully you work on an team where they understand the human nature of what we do and they will help you get over it. Regardless, learn from your mistake and keep on going.
Programming can be a fun and rewarding career. There is always a problem to solve and if you like problem solving it is a joy to work on them and get paid for it.
Software development is also well paid, and although money is not everything, it is certainly rewarding to get paid well for what we do.
But software development is not perfect, there is a lot of sexism and discrimination in our field4 just like there is in society at large. I cannot speak about how it compares to other domains since I have always been a software developer, and being a guy in software development comes with certain privileges, but discrimination in our field exists and I hope we all can work together to make the field more inclusive to all.
At the beginning your career options might be limited, but as you go you might have the opportunity to work in many different kind of fields and many different kind of projects. You might work on small application with a small team or in a large application with a large team, you might write applications that are purely for entertaining or applications that can save lives.
No matter what your journey looks like at the beginning, keep learning, and enjoy the ride.
No, I don't think to.
I wrote this post based on the materials that I used a couple of years ago when I gave a presentation to a few Computer Science (CS) undergrads about my career story, and therefore my story starts during the years that I pursued my CS degree5.
A degree in CS has certainly helped me, but I have worked with many talented developers that didn't study Computer Science to begin with. Some of them started programming right after high school and became really good at it. Others had an undergrad degree from an unrelated discipline (say music or business administration) and became really good software developers.
If you don't have some of the foundations that a CS degree gives you, it's up to you to get them since you are going to need them at some point in you career. Unfortunately this kind material tends to be a bit academic and obscure and hard to get started with on your own, which I think that's where a degree helps since you have people helping you learn the ropes. But there are resources to learn them outside of a formal college degree.
[1] I wrote about my first experiences with Ruby in 2011 and about my journey as a Ruby developer in 2019.
[2] If you look around the topics in my blog you'll notice how my interests have shifted over time. There are posts about technologies that no longer exist or that I don't use anymore. Or this article that I wrote in 2003 on how to deploy applications over the wire, so quaint, err, I mean so obsolete.
[3] If this is news to you I recommend the books Algorithms of Oppression: How Search Engines Reinforce Racism by Safiya Noble and Race After Technology by Ruha Benjamin on the subject. The piece Knowing Algorithms by Nick Seaver in digitalSTS: A Field Guide for Science & Technology Studies is also a good place to start.
[4] There is a reason Felienne Hermans wrote A Case for Feminism in Programming Language Design and Charlton D. McIlwain wrote about the erasure of the contributions by African Americans to computing and the internet in Black Software.
[5] The slides for that presentation are available here.