Software engineering - why do I do it?
Software engineering is awesome; I love it. Just think what we are doing. For the most part we are constructing entirely imaginary products. Entirely virtual, only visible by their effects on the world. On the one hand, people could say this makes the work less satisfying. I’d say it’s the opposite. We fight entropy, creating order out of chaos solely through our thoughts and our encoding those thoughts in the languages we use. That’s awesome.
The order we create may be judged mundane, depending on the domain we work in - financial, pensions, etc. That doesn’t matter. The act of bending raw input data to our will is amazing. Our work overall affects almost every aspect of our lives and we’re processing data to orders that produce scarily accurate machine learning systems (even if they’re not yet self-aware).
I’m a contactor because of the freedom and opportunities for learning it provides. Each contract can be a new domain - financial, document processing, biomedical, education. All new experiences and new domains to master and convert to code. Being a contractor also means working to fixed goals. There’s no putting in your 35-40 hours a week without ever caring about what you do in those hours. Ok, contracting doesn’t automatically negate that (and I’m not saying it’s an automatic outcome of being a permanent employee), but it’s how I choose to perceive my work. I have a fixed goal and a fixed timeframe. I know when I’ve won. I don’t need to spend months or years sitting around filling time waiting for the next fun project to come along; I go out and find it. When it gets to the stage of a project just ticking along, there’s no need for me to be there anymore - time to move on.
That’s not to say I favour greenfield projects, leaving maintenance work to others. I really enjoy working on existing legacy systems - they’re usually large enough to be interesting, and messy enough (after having grown organically over the years) to benefit from a serious refactoring. I love refactoring. Again it’s the production of order out of chaos; it is very satisfying.
Teamwork is another big part of the appeal. It’s difficult to describe the fun to be had in a good (XP) team. The sense of achievement we get adding business value to a system every single day. In those teams I come to work with a smile on my face, that generally lasts the day. It’s just so much fun; and I get paid for it ;) How cool is that?
It’s not all roses I’ll admit. There are many organisations that are just plain toxic. Full of nasty, petty little jobsworths. Bureaucracy has a habit of incubating such environments - generally the larger the organisation the more likely it is to occur. For a contractor though, it doesn’t matter. Back to the fixed goal and timeframe. If your goal is achievable, then just get it done, get the money and leave for somewhere more interesting. If the goal is not achievable (generally because of the inefficiency of the organisation you need to work with) then you have a choice. Continue putting the time in, billing, and trying to produce something useful, or fail fast - acknowledge the effort required will not produce the business value expected and bring it to the attention of the stakeholders. Let them be aware of the issue and give them the option of restructuring the goals, or even canning the project rather than continuing wasting resources.
I favour the latter approach - it’s just no fun staying on a deathmarch project solely to invoice the maximum out of the client. As described above, I’m largely in this profession for the sheer joy of the work.
Shared at https://www.linkedin.com/pulse/software-engineering-why-do-i-donal-stewart