posh.wiki

When I started my software job in 2023, I had some very incorrect presumptions about what I would be doing. I thought that most of my time would be spent building new things, i.e. "developing".

In my first few months on the job, I quickly learned that there was a lot more to it. Enterprise software development isn't nearly the same as building random little tools or coding on a whim for strangers on the internet who have functionally no impact on your life. It's really about the people, and the people are... Well, idiots.

Of course, I'm too harsh - It would be more accurate to say that many people believe they have a complete understanding of systems when in fact they have a limited perspective, and struggle to comprehend any information that doesn't fit with that vote. Sometimes they act in ways even they cannot logically justify, probably because they're constantly stressed about losing their livelihoods.

Because of this, one of the earliest lessons I had to learn was how to communicate. That was some feedback I received in my first annual review, and I was lucky enough to have someone on my team I could take after. I learned that it's not entirely about conveying information and creating understanding, which I've noticed is a style I tend towards. Instead, it's about keeping people's egos at a sweet spot and leaving a paper trail to absolve yourself of responsibility for various failures.

Some advice I can give on the matter is to make sure you have every request you make and fact you convey in writing (this can be done in the form of summary emails to attendees of calls and meetings), and try to make people think that the optimal solution is their own idea instead of telling them that their ideas are bad and they should feel bad. Another big part of it is confidence - one must learn to take initiative and speak up first. I worked on this by starting to attend public events - most user groups and lots of conferences are free (especially if you volunteer there), plus non-software things like furmeets and local craft groups.

I didn't get an annual review on my second year. I'm not sure why, I guess people were just busy. Over the past year, I'd been given bigger and bigger tasks, and I noticed that my larger solutions were a little bit clunky. Changing one thing in one place would often break something completely unrelated in some other place, and adding something new would often require major changes and shuffle-arounds. I decided that, for the coming year, I would focus on architecture.

I've found that the customs and specifics of architecture depend not just on what you're developing, but also which language you're using. C# is one of the thousand attempts at making "C with classes", so naturally C# developers gravitate towards more object-oriented designs.

Beyond that, I've found the onion architecture to be very useful. If you use the C# project system correctly, you can make it heuristically impossible for your domain logic to be aware of the UI, API, CLI, or other "I" that's consuming it, which makes for a more logically robust system that won't break process when the UX changes. It also has the added benefit of allowing multiple user front-ends to share the same code, which reduces inconsistencies across various means of user interaction.

Thinking interms of MVVM - model, view, view-model - has also helped me a lot. Essentially, it de-couples presentation logic (the view) from the core logic (model) and bridges them with a layer of indirection (the viewmodel).

The best piece of advice I can give with that, though, is to get out and build things. Big things! The best motivator to architect well is when you are feeling the pain of poorly architected code. Working on real projects really helps you identify pain points that are mitigated with architecture and get real world practice with implementing the solutions.

Another thing to note in the world of architecture is discipline. There are ways to make the compiler work for you in some aspects, but you must resist the urge to fight against it for a faster fix. For those concepts that can't be caught by the compiler, it's important to really think about not just what you're writing, but where you're writing it. How will this fit in with the existing system? How easy is it to swap out with a different method of accomplishing the same effect? How easy is it to extend? Am I optimising for the right cases? These are all questions you learn to ask every time you're building something new.

As I write this, 'tis once again the season, and once again I haven't had an annual review. This year, I've made the resolution to work on being business-minded.

Of course, there are many ways I am accidentally business-minded already, by being cheap. It's a well known fact that I love free and open-source software, both because I can understand and tailor it without hinderance or restriction, but also because it's pretty much all I could use as a broke teenager learning to code. I also tend towards cheaper solutions where possible, for example this site, which is hosted for free because it really has no reason to be anything other than a set of static files. Even when going to conferences, I pick the cheaptest hotel and don't go to any fancy restaurants because, frankly, I don't need a massive room with a skyline view or an elaborately architected meal in a fancy restaurant. I could sleep on the floor and eat bread and water and I'll still be perfectly happy.

But I think, by my nature, I am a problem solver. People bring me problems, I fix them, no questions asked (beyond what's necessary, of course). It also never occurs to me that I could charge someone for a service, in part because I am so staunchly anti-capitalist, and in part because I have no involvement at all in quoting and invoicing.

The problem is that there should really be only two people bringing me problems: my boss, and occasionally the customer support team. Unfortunately, some customers have realised that coming to me directly gets things done faster and cheaper. For technical support, they skip triage, and for new features, they skip the consulting process. As a business model I gather that's largely not sustainable - we need to charge customers for their new features and investigations into issues that turn out to be their own fault.

I suppose it's not entirely incongruent with my ideas of the economy to expect to charge for this, because the charge is going to a business, rather than from the wages of the person who caused a problem or wanted a feature. Still, though, capitalism is evil and every man should give as he is able and receive as he needs.

So, my immediate resolutions for this year are simple enough and honestly quite cathartic: if I receive a request directly from a client, I'll check that it's been triaged or quoted before actually attempting to fulfil it (and tell them to screw off, nicely, if not). On top of that, I'll make an effort to better track every minute I spend fixing issues, and bill them if it turns out to be their own fault.

I anticipate there'll be more to learn about the business too, surely. The fundamental idea is to minmax money out vs money in, I get that, but there's far more to optimising that than just making sure businesses are billed correctly. I've never been one for those SMART targets, I just have a general idea of something I want to improve upon and I look for small ways to do it in my daily life.

It will be interesting to see how that integrates with my improvements in communication, because I'm sure it will upset a lot of clients, but hey, business is business, I guess.

Ultimately what I want this post to convey isn't so much my own self-improvement, though. Moreso to dissillusion people of the idea that working in software is just 24/7 building. In reality there are whole days where I don't get a chance to work on something new because I have to spend all my time dealing with short-term problems that may turn out to be trivial, imagined, or just plain stupid. It's still a great career, don't get me wrong, but it's not exactly what I thought I signed up for!