Skip Navigation
105 comments

  • You're not responsible for the bad decisions made by the people who have positional authority over you. Do your best. Warn them about the risks. Let yourself feel disappointed by their decisions, but don't ever accept responsibility for them. If you did your best to warn them, then you took your responsibility seriously. That's enough.

    • CYA in a nutshell

      • UPDATE: I added some clarifying points in light of getting some of this wrong. I believe the underlying point still stands.

        No. I believe I understand why you think so, but just no.

        At best, covering your ass means gathering evidence about how much you tried to warn the people making decisions, in order to avoid or deflect blame when things go wrong and someone starts wandering the countryside looking for people to blame. I'm not suggesting that. I'm not even suggesting saying "I told you so." when things go wrong.

        Quite often, at least how I've seen it, covering your ass involves not even trying to do the right thing or, perhaps, pretending in public to do the right thing in order to have a plausible excuse when things go wrong. That's also not what I'm advising.

        I'm advising not to accept responsibility for other people's bad decisions. If you genuinely did your best to influence their decision and they chose poorly anyway, don't take responsibility for that choice. The responsibly remains with the person who had the authority to decide.

        For example, if the OP decides to listen to you instead of to me, that's not my responsibility. I've tried to explain my position, but the responsibility for choosing what to believe belongs with them. I'm most definitely not covering my ass; I'm recognizing that I'm not responsible for replacing OP's judgment with mine. If they ask me for more information, I have the responsibility to provide it. If they ask me to clarify my position, I have the responsibility to do that. But I am not responsible for convincing them nor for their final decision.

  • Understand that technology cannot fix people problems. Always remember that. If you're asked to solve a people problem and you don't understand it, you will suffer. Only management can fix people problems.

    • Also, it may not seem like it, but software is almost entirely about people. Everything comes down to the users. You need people to use your software. You need people to want to use your software. Even if your users are other engineers, you still need users. You could build the best piece of software ever made, but it's nothing without usage.

      Things like marketing, product, and design are usually equal parts of building software.

      This is something that took me a long time to come to terms with.

      • Yup. It's definitely always about people. The people using it.

        I've worked in software support, QA, and technical writing.

        A LOT of developers who come in as devs from the very start of their careers know very little about how the average person might interact with the software they are creating. And what they know of, they can (sometimes) be so sneering and dismissive of that it actually impacts their design decisions. Like, "I don't care, the user is stupid, I'm doing it the RIGHT way." Even when the "stupid user" is like 90% of the population that'll use your widget.

        A new (and old) dev should read past customer tickets and talk to your customer support people, as they'll have the actual real-world experience and examples with non-technical users that can give you insight into how to better create the thing that you are creating.

        To make a comparison...say you were a furniture designer making chairs, and you're 6'3". Sitting in the chair yourself and proclaiming it's fine isn't enough if your users are children, women, guys shorter than you, people lighter than you, people heavier than you, and the disabled. You need to actually understand how people who navigate the world in a different way than you do interact with the thing you're making. A chair that works fine for someone who is 6'3" with two working legs might be unusable for a 11 year old who broke their foot, or a 4'11" grandmother who can no longer move heavy things around (say if the chair is solid and heavy and something a 6'3" dude could easily move).

        With technology, it means average non-tech users will flow through menus differently than you, might have vision or hearing problems that you don't have that make signals from the widget difficult to decipher, and people in general who are non-techie can also be more risk-adverse when it comes to things like clicking strange buttons. And that's just the tip of the iceberg.

    • Interesting, mind giving an example?

  • Everyone else here who said, "Keep learning" is right on, but don't forget to work on your soft people skills along with your tech skills. Whether your long term goal is to stay in development or some other aspect of the industry, you should be comfortable talking to all sorts of people (management, sales, customers, etc...), making presentations, being social at conferences and so on. We (techies like me) tend to forget this, but it's really important.

    Imagine yourself starting your own company in five years or being the senior manager of a large group. How are you going to like meeting new people every day, selling or at least explaining your product or service to them? If the answer is "not very", then start working on that now.

  • Ask questions, don't assume. Keep notes of meetings, and notes of your work, little bits. Always have a good rollback plan.

  • If you're offered a job with more money/benefits or whatever, take it. Don't give your employer the option to counter. And if you ever do let them counter out of curiosity, don't take it... Leave.

    There's too many horror stories of people basically staying on after a counter-offer, only to train their replacement and end up tossed out anyways.

    Loyalty doesn't mean shit in tech; any promotion you get internally at a job will be pennies compared to what you're able to get by shopping around; so do yourself a favor and run whenever the opportunity arises.

    • YMMV; staying can work well but you really have to know your employer, and be able to roll with the punches either way. It can be equally risky to be the new guy again. Always have an honest understanding of your replaceability.

      • If you're irreplaceable, you're probably doing something wrong, at least in tech.

        All technical fields especially should have a high bar for documenting what you do and how you do it, requiring documentation in every form and for every aspect. In my field, IT support/sysadmin/network admin, process, procedure, common fixes, system set up, network design, etc should all be documented. The only down side to having to replace me should be the long lead time for the new person to chew through the documentation to fully understand what's going on and how it's all interconnected, and not much more.

        IMO, person to person "knowledge transfer" as my current employer currently implements, is unviable, and should not be allowed to be the norm. There should never be only one person at an org that knows the job, and the current state of affairs and why the current state is what it is.

        If any org does have that single worker point of failure in knowledge, then they're just one incident with a bus away from significant risk of their systems entirely collapsing. I call this the individuals "bus factor", aka, if you're hit by a bus, how fucked is everyone else? An IT person's bus factor should always be low since almost all businesses are data management companies that make money doing X; everything from users Rolodex, to the CRM, to their communications and daily working tools, are almost always entirely dependent on IT, in some way, shape, or form. Less so for companies doing non-computer controlled manufacturing, but any desk job, or white collar office would entirely collapse if their IT staff was suddenly unavailable and their IT environment was to go down. At that point, just close up shop.

  • you will end up bringing down production or make a however many tens of thousands of dollar mistake. Don't worry about it too much when it happens. That sort of thing doesn't usually get you fired the first time.

    • Be transparent about your mistakes and learn from them - better yet, help make sure others won't make the same mistake.

  • Don't get overwhelmed if the task seems too difficult or complex. Take time to write it out on paper, break it down in smaller parts and tackle them in turn.
    But... Also be honest with yourself if you're struggling, there's no shame in admitting that you need the help of someone more experienced.

  • Here is what I did. I bought an IBM ThinkServer and put as much ram as I could in it (32GB; keep in mind this was 2015). Then I loaded it up Windows Server by itself and played with the Windows and its features. Then I loaded Hyper-V to play with virtualization and created my first domain environment, learning DNS, DHCP, GPOs, an Exchange Server, and VPNs. I ended up throwing a 4-port NIC in there and set up pfsense on a VM to act as my firewall router so I could learn VLANs, traffic shaping, and security. Then I put ESXi on there and learned vSphere and vCenter. You can sign up for an NFR key from Veeam and play with backing up a virtual infrastructure.

    There is so much you can do. I started out on Helpdesk in 2015 and now I am a Senior System Engineer that works with the VMware platform all day. If you invest in yourself, it will directly invest in your future and how quickly the promotions happen, and the amount that the responsibilities increase. Feel free to reach out and DM me if you have any other questions that I could help with. Good luck to you!

  • Do some study in your own time.

    If you aren't sure what to do and like servers etc, just do the Microsoft courses. Having these on your resume gets you ahead of people that don't have them at all.

105 comments