Emmapedia

There is no such thing as Emmapedia

But, this is how I work:

• Get rid of your comfort zone. Honestly, if you need a comfort zone for doing your IT job, you haven't done enough automation.
• Be honest about what you know, and what you don't know. People appreciate the information that something isn't a fact but a guess. And if it's an educated guess and you were right, they'll be happy you pointed them in the right direction anyway.

Then:

• Search through the documentation. Usually it's very outdated but if you happen to have a Confluence instance or something similar, search it for whatever you want to know. Be creative with the search terms you use.
• Search your corporate IM tool, like Slack. Do you have Slack? it's highly searchable, and chances are somebody in your company already did what you're trying. Really. There might even be a separate channel for it.
• Search your mailbox. It could be you helped someone three years ago and that you just forgot how to do it.
• Are you troubleshooting an application that was developed internally? Search your VCS, like Github, Gitlab or Bitbucket, for instance the error message you received.
• Look where the application is logging to. Read the logs. If there are no logs, the application just might not be able to run at all. Increase the log level if necessary.
• Use your dig, netcat, traceroute, curl and netstat ninja skills to find out where an application runs, if it's reachable, if it responds, and if it's running. Also, figure out which PowerShell equivalents exist, so that you can do this on any system, MacOS, Linux or Windows.
• Working in IIS web applicatons? Web.config could tell you something about the systems it connects to. And if it's a web application in Azure, these things are probably in the properties.
• Speaking of Azure: create yourself an FTPS account and use it to browse Web Services' file systems with Kudu
• Still no luck? Use your Google-fu. There's very little that cannot be found on ServerFault or StackOverflow.
• Read faster. The internet is a big place. Google will return a lot of rubbish. You'll need to be able to skip that in seconds instead of minutes.
• Be strict when it comes to security, no matter if you're a security officer or not. If you see anything that's not right, from a password stored in the VCS, to a gaping hole in an application's authentication mechanism, DO SPEAK UP. Someone might hate you for it now, but that's entirely their problem. Someone will thank you for it later on.
• Do not trust whatever your AI agent tells you. If something is off, ask for details about it. Ask for sources, and check those, don't get caught up in an AI induced gish gallop. I have seen ChatGPT answers with sources and annotations that were entirely made up.
• Vibe coding isn't inherently bad. Vibe coding without a plan is. Before pitching an application idea to your favourite agent, decide for yourself what the software should do and what it should not do. Make a list of acceptance criteria, and tell the agent to first create a plan and divide it in epics and stories, just like you would do with a classic software project.
• Get the right plugins and skills for your agent. Software architecture, UX design, cloud infra, documentation retrieval and documentation creation: use them.
• Sometimes you need to create your own skill. There are skill creation skills and plugins, check them out. Skill building rule 1: explicitly forbid the agent to update the skill. Rule 2: tell the agent to add new insights to a secondary file, that never should be used as a source of information. Then, you can periodically separate valuable skill insights from opinionated one-offs and authorise the agent to move the valuabe bits into your skill.
• Cloud providers have all kinds of solutions for all kinds of problems. Databases, queues, storage, VMs, event loggers, function apps, container clusters, 20 ways to serve web sites. I'm kind of convinced that we're slowly moving to everything containerised, so that clusters like Kubernetes can be moved more or less freely between cloud providers, or to have services spread across providers. If you have continuity requirements like NIS2 you cannot put all your eggs in one basket, or have plans ready to move your eggs into another basket within hours.

You already knew that?

Good! It took me a while to come up with this list, and it's not even halfway. (Note to self: I think I can leave this in for the foreseeable future, even if the list becomes ten times as long, or if 'halfway' proves to be all there is.)