Mac Does Stuff

Month: June 2022

  • Mac vs PC – Really?

    There’s a question I’ve come to dread: ‘Why do you use a Mac?’. It’s always centred on the fact that probably 90% plus of my work is on Windows + networking infrastructure. Very few bits of infrastructure are MacOS based.

    Why do I avoid it? Well, mostly because the person asking it usually has a predetermined position and they’re itching to give it to you. It’s rarely interesting.

    Objectively though – why? Well, my opinion is changing, and my choices are evolving. That is interesting. First, let’s cover why it wasn’t interesting before.

    Primarily it’s because there was nothing you can do on Windows that I couldn’t typically do on my Mac. WAIT you say – Visio? Microsoft PROJECT? OMG OMG. Well. Virtualised I can run both of those things, as well as much other Windows software. It isn’t a key decision point for me.

    What this means is that my reason for using a Mac was subjective. I just liked the operating environment more. Did it make it more productive….? Arguable as to whether it does or not. I just preferred the look/feel and how the apps worked.

    What about hardware? Well, I’m sure there were many better hardware platforms out there – Dell XPS came pretty close for me for example. Again though it’s subjective. I get to use several Windows machines and they’re very capable, and they could have done the day Job. I just subjectively preferred the MacOS environemnt.

    One of the absolute key strengths I really embraced with my Mac was the ability to virtualise so much stuff, so quickly. I would have separate environments on a drive and I could quickly power up Skype or Exchange or many standard environments. On my laptop. It was hugely capable. Was.

    Wait you may think – what about Hyper-V? Or VMWare Workstation? You can do that on Windows. You can, and I’d refer you back to my previous point about subjective preference over actual real objective points. I just preferred it in MacOS. Hyper-V was particularly irritating – it didn’t scale as well on my local machines and I’d often run in to odd issues usually to do with networking. I’d rarely run in to stuff like that on my Mac.

    I ended up using my Mac more like I would an appliance – I just didn’t really get involved in tweaking it, or fighting to get bits working. That sometimes wasn’t my experience on my Windows equivalents. It was a preference choice though – not one that would fundamentally affect my ability to do stuff.

    Now though – well, it’s all change. The Apple move to ARM has removed a big key point of my preference – virtualisation. I’m finding that I’m running stuff on my home systems and connecting to it remotely – which is fine of course, but it’s an extra step and requires planning. I miss being able to quickly just fire up an environment.

    I was today trying to think about then why am I still on a Mac? My main laptop for example is a 10 core 64GB/2TB 16″ ARM MacBook Pro. It absolutely flies. I’ve not got close to using that RAM simply because of the virtualisation restrictions. I don’t think I’ve used such a capable machine with simply ridiculous battery life. There’s an issue though – it no longer really does enough. In reality the real reason I’m still using my Mac laptop rather than switching back to say an XPS, is really Apple Photos, Final Cut Pro and….. familiarty… That’s it.

    Microsoft is now of course (apparently – again) embracing ARM so perhaps things will change in a few years, however for now my MacBook Pro is becoming a media machine, and I suspect my day job will now be XPS driven.

    Weird how things come around isn’t it? It’s interesting to see the fervent arguments each way – I’m not one of those arguers – usually. I just have – had – a preference. The problem is my preference is now making my day job more difficult, in that I have to plan for other methods and other ways of getting stuff done.

    That isn’t cool, and no amount of looks nice or familiarity can overcome that.

  • The Art of Technical Documentation

    I got asked something the other day, that while a simple question, took me some time to ponder and fully answer. Why do I produce so much documentation for stuff?

    First, some context. I spend most of my time designing, deploying and even sometimes – operating – mid-market IT systems. Mostly Office365 and Unified Communications areas, as I find them the most interesting. By mid-market I tend to focus on the up to 10k seats area. Mainly as I find that’s a size that’s manageable and you spend most of your time actually doing the interesting technical stuff rather than lots of incremental minor things due to risk management. I have worked on big stuff – some of it properly big (400K+ users) – and while that has it’s own attraction and interest, the mid-market I find more interesting.

    Over the years I’ve developed a solid strategy for dealing with complex systems, and managing change. I don’t mean the formal change management processes – they of course have their place – I mean how *I* manage what I’m doing, how I establish the outcomes I want, and how I get there. This is the bit that tends to produce a lot of documentation.

    Let’s imagine we have a requirement to implement a reasonable amount of change for a system on a remote site. My documentation process will follow this methodology:

    • The why and the what. Here it’s a brief to ensure that everyone understands what’s being asked for, why it’s being done, and what the expected outcomes are. This has been vital in catching some misconceptions/differences between people.
    • The how. This details how I’m going to achieve what is being asked. All touch points, impacts, expected outcomes etc. Also includes how we roll back. This is often included in the change management process.
    • The doing. What happened when we implemented? This is great for lessons learned and for future similar projects.
    • The final state. Sometimes referred to ‘as is’ documentation.

    This feels like a lot doesn’t it? It really isn’t in the real world. I’ve been following this process for so long that it’s second nature to me. It has some very specific pay offs too. I have a complete audit trail of what was asked for, what was agreed, and what happened when we did The Thing. That’s come in very useful in the past.

    Do you know what’s really important about the process though, that I think is often missed? This process helps me vastly reduce risk in increasingly highly complex systems. This has been a developing area in the world of technology (Complexity Theory), with a key part of it being Systems Theory. Understanding how one system is dependant on another, and affects several others – it’s challenging. 

    This documentary process then – for me – is a lot more than just the documentation. It’s a process of fully understanding a requirement, establishing how we get there, and then helping the people running the systems also have a handle on it after we’re done. The process is arguably just as important – if not more so – than the documentation itself.

    This is the bit I find interesting, and it took me some time to explain. 

    The pay offs from this process are several. From a freelancer perspective, this makes me reliable. Typically I achieve what I am being asked to achieve, and usually in the manner we’ve planned and agreed. Another key pay off, is that it makes me look at the technology I deal with in a lot more detail than is perhaps necessary for specific items. That always aids understanding, and that is never a bad thing in technology.

    Anyway, a simple question, not such a simple answer. Writing good documentation is also challenging in the technical space as you have a wide range of readership to consider, but that’s a subject perhaps for another day.