It's that darned web developer guy! (Or lessons learned by wearing a new hat)

Back in October, my son’s robotics team said “Hey! You work for a software company, can you build us an application that will help us with scouting and competitions?” Foolishly, ego stepped in before a careful outsourced review of my existing skills could take place, so I said “Sure! Not a web developer, but how hard could it be?”

Seriously…how hard could this be? I see web application traffic all the time. On the wire. And I can even manipulate that traffic at the protocol level and do amazing things with it programmatically. But…changing application traffic in flight is not development of that application. Nor is it an understanding of all the considerations one must evaluate and handle to get from idea to solution. So yeah, it is hard. Dang hard. Actually, getting to a dynamic web experience "hello world” is easy, but getting to a working application? Not so easy. Or quick. And rightfully so. Skills take time to master, and mastery unlocks new levels with which to master.

You may be asking yourself what any of this has to do with DevCentral? The project may have been unrelated to my work here, but the lessons I learned apply in several ways.

You don’t know what you don’t know

I addressed this at the end of the year in another article so I won’t bloviate here, but basically, the lesson is this: ask questions and a lot of them. Don’t fear “that guy” that puts you in your place if you ask a dumb question or simply don’t know enough how to ask the question in a way that communicates the problem. And definitely don’t be “that guy” if you are already in the know.

You don’t know what you think you know

This one snuck up on me. I’ve been working in and around html and http for years. YEARS. But I had no idea that when you submit a web form that boolean fields are not transmitted with the form if the value is false. So if you have a piece of code using said boolean field to insert that field into the database column, it just might (read: it will) go belly up when you try to do the insert. Because it’s not even there. Building in checks to make sure that field is there and setting to True if so and False if not solves that problem. Didn’t have a clue it WAS a problem until this project.

How many more nuanced issues like that exist in the protocols I am responsible for managing every day? How might that impact how I go about rewriting content or inspecting for content in an iRule or security policy? Learning more about the technologies on both ends of the application delivery infrastructure only serves to enhance your skills as a technologist.

You don’t know what they think you know (or vice versa: you know what you think they know)

This one is two-fold, and rests in the world of assumptions. I may be ignorant of something they assume I’m clued in on, and they may be ignorant of something I assume they are clued in on. Either way, it serves to create an "us versus them" divide (as I suppose I just did with the section header title!) that keeps valuable information close to the chest, either intentionally or inadvertently because we think we know it all.

Humility goes a long way to admitting that we might have a gap in our high level understanding and our ability to execute on that understanding. For example, I get how relational databases work conceptually, but I haven’t really built and managed one from scratch, I’ve always used someone else’s table schemas on well-established projects. So taking the concepts of foreign keys and relating columns to columns in other tables was something that took some serious thought. And then some rethought. And then some white flag moments with Mo and Scott who work on our web platform here at DevCentral.

Knowing that I have concept->implementation gaps from my infrastructure perspective enlightens me to the fact that my web developer peers likely have similar gaps coming the other way. Rather than rolling the eyes at “that darned web developer guy,” I ought to take every opportunity to humbly offer to fill in those gaps. It helps all of us. This is something we can all do as we ask/answer questions right here on DevCentral. Most of the time a quick ask/answer is fine and is all that is called for. But when the opportunity to share the why behind the how presents itself, take it!

What’s in a name?

Web developer is a shifting term like cloud. Ask twenty people to describe one and you’ll likely get fifty definitions. Here are a few of the roles I’ve run across while researching. I’m blessed to work with a great team of developers who fill many of these hats on the development of devcentral itself and took the time to answer my questions and provide help along my journey.

• Full Stack Developer - this is the everyman, and the role I played on this project. You do it all soup to nuts.
• Network Administrator - the network guy. Sets up all the paths and permissions and assigns the addresses to get you connected.
• System Administrator - the underlying systems guy. Installs the applications, frameworks, and plugins you need.
• Security Analyst - reviews your plan of attack, protocols and applications in use, systems utilized, reviews codes, pen tests the application
• Database Administrator - designs the schema, deploys the databases and changes, reviews the application models interacting with the database
• Application Developer - designs / develops / tests the model/view/controller aspects of the application. 
• User Interface Developer - designs/creates the layout and style
• User Experience Developer - refines the layout and style as well as functional validation and messaging

Good tutorials are plentiful. Great tutorials are hard to find.

I made it from zero to deployment in less than a hundred hours of work, learning included. There are a lot of good tutorials and helpful articles on all areas of the full stack. With my framework of choice, python flask, the gold standard for all tutorials seems to be establishing a blog site. Some are better than others, but they are all helpful. The challenge is moving from good to great. Analogically, it’s helpful to see spot run. And you can find ways to see spot run in every tutorial. But to continue with the analogy, if you want to see spot run, stop and bark, pee on the fire hydrant, then run off, well, that is harder to find. That’s also a reminder for me as I write articles for DevCentral going forward, and for you as you demonstrate and explain to peers on DevCentral or in your immediate circle of influence. Go the extra mile to explain the processes beyond the simple examples.

If you want to be a $your-dream-IT-role-here, the world is yours.

Whether it’s web development, network administration, hardware engineering and design, or application delivery architect, there are so many good tutorials, videos, articles, etc, out there that the world is yours. If you want to grow in your existing career path or change it, the world is yours. Go grab it by the horns!

What lessons have you learned being stretched in skills outside your immediate areas of responsibility? Please share below!