This content originally appeared on DEV Community 👩💻👨💻 and was authored by Bruno Noriller
The name is cool, but you could say it’s not all… sunshine.
Question: what do technical and non-technical people alike get wrong? Read and find out!
Shadow IT
While you could just go to Wikipedia, you probably waiting for me to give a primer. Fine.
Nowadays all big companies are tech companies, even when they aren’t. It’s not even an opinion anymore but a fact.
The corporate, official, IT teams can’t manage all the demand for tools from all departments that need them and people start solving their problems themselves. Sometimes the official IT can give some support, other times they simply overlook and sometimes they try to squash those developing in the shadows.
The “citizen developer”
A new trend is that everyone needs to, at least, be able to solve their own problems. They call them the “citizen developers”, that will use “low” and “no“ code solutions sanctioned by the corporate IT to do that.
My experience
If you go through my other posts and links you can probably piece together that I too am a developer in Shadow IT. (Either that or, you know, you just read the title. But I’m sure it’s that you've gone through my links 😉.)
Back then
As you know (or just discovered), I’m actually a business bachelor and started my programming journey about six years ago.
The problem of “Shadow IT” is not new, but some companies had already started to train more “Citizen Developers” for quite a while. In my case, I had weeklong training in MS Access (back then I was already an “Excel guy”) and as a footnote, because the teacher was able to go through everything they needed, there was a single class in VBA (looking back, while it was… visual, it was far less than the basic!).
I then was put into a team that needed to feed this one internal system… manually. They were literally throwing people at the problem because an entire team was allocated to basically just do that.
If this rings a bell, you’re probably remembering my first post because it was a mind-numbing job of click, copying, and pasting ad nauseam. I turned to my boss and said: “I can probably automate that” and since there wasn’t much to lose, she said: “go ahead”. And so my first application was a web automation tool made in VBA and Excel.
In my second one, I automated email sending (think direct mail) and those two alone saved thousands of hours for my department, are prime examples of Shadow IT, and put me on track to become a full-fledged programmer. And all I knew back then was the VBA (the Very Basics AboutProgramming), seriously! I probably didn’t know anything more than assignments, if, loops, and goto (yes, VBA has goto and I abused it).
Today
I passed through a few languages and frameworks after VBA: Java, JSP, jQuery, Angular, Python, and finally my current bread and butter of Javascript, Typescript, React, and Node.
Today I consider myself a programmer (for me, every programmer writes code, but not everyone who writes code is a programmer) and I strive to deliver quality software even with all the limitations the corporate IT puts on the Shadow IT teams.
I have to fight proxies designed for non-developer employees, documentation, and internal APIs that they don’t really want us to know anything about (like the LDAP authentication and even access to basic tables from the internal data lakes). When something changes, the Shadow IT teams will be the last to know, and just because people come complaining about things starting to break.
While you think I’m complaining (maybe a bit), this led me to be flexible and focus on solving the problems. Aside from programming, I had to do a lot of DevOps “stuff” on our servers and learn by doing, breaking, and fixing stuff all the while maintaining a dozen applications and Excel spreadsheets with macros.
The biggest lesson learned
Finally, answering the question I raised first: what do technical and non-technical people alike get wrong?
Programming is just a tool to solve problems. No more, no less.
Technical side
Technical people focus too much on the implementation and not enough on the actual problem.
Last post I even talked about it!
Sure, I could give a “spreadsheet” on the web with some forms that my non-technical colleagues described as what they wanted.
But that wouldn’t solve their actual problems, technical people are quick to think about how to make those web spreadsheets and not to stop the person asking for it and ask: “Are you sure that’s your problem?” (And yes, like probably every programmer, I also get that itchy, but I learned to suppress it.)
Non Technical side
On the other side, we have people who may be technologically illiterate, that don’t know what can or not be done, and who sometimes think that everything is almost magic, so you can just “drag and drop” and it’s done, “so it’s easy to do, right?”. (I wish this was just a hyperbole.)
They also focus too much on their version of what they want and not on their actual problem. After all, we all like to have a shiny new toy to play with right? And some in upper management love to brag that “they came up with the idea to…”.
Yes, a lot of drop-down inputs would normalize the data, avoid gross human error and reduce time… but why click at all?
Some people come wanting a “better version” of the process they do manually with pen and paper and that is only on their head. (Again, I wish this was just a hyperbole)
The Shadow (IT) Developer side
I can see both sides. And personally, I still have what I learned in business school and all the programming experience.
I like to talk to the people who will be mainly affected by anything I have to make.
- Who is responsible for the process, and how is it currently being done?
- What are the “tricks and tips” they pass to new people doing that job?
- How does that little cog fit inside the bigger machine?
- Who is it that will have to use the solution?
- What is the best-case scenario with as little work as possible?
- And what are exceptions that might need to be done differently? Are they even the same process? (Note: sometimes it might seem, but it’s actually different things.)
These questions alone will give you insight into how it is to how it could be in a perfect world.
And if you read the list again you’ll see that I didn’t mention programming. Because sometimes a better spreadsheet will be the right answer. Sometimes you can simplify the process without any crazy new complicated tools. Really! People underestimate the benefits of just taking a look at a process and just improving it.
Shadow IT teams are usually small and everyone needs something. Knowing the “fights” to fight will always bring more than just “upper management wants you to do this”. Something might be really important, but if it can be done quickly and without pain, why not invest in solving that unimportant task that consumes hours of people every day?
AMA
To be honest, I’m always awkward with closing my articles, so this time I’ll just leave it open for you to share and ask anything, and if there are no questions I’ll just know that I awesomely managed to pass everything flawlessly.
🤷
Cover Photo by David Werbrouck on Unsplash
This content originally appeared on DEV Community 👩💻👨💻 and was authored by Bruno Noriller
Bruno Noriller | Sciencx (2023-02-05T16:15:43+00:00) The life of a Shadow (IT) Developer. Retrieved from https://www.scien.cx/2023/02/05/the-life-of-a-shadow-it-developer/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.