My age was just a single digit when I wrote my first “Hello World” program (in BASIC on an XT, if you’re really curious). I still vividly remember the feeling of accomplishment after seeing those two words printed on the screen. This, my first coding experience, put me on the path to writing code for a living. But as I would learn much later, not every software-related problem can be solved just by coding. The toughest ones require much more than that.
This chasm we rarely speak about, between coding and developing, is one I fell into when I got my first dev job fresh out of college — and it took me a while to climb out of it. I felt completely unprepared. Yes, when given a specific function, I could understand and modify it, but that wasn’t what the developers around me were busy doing most of the day.
I looked up to them as they were solving problems, putting out fires, designing new things from scratch. Their skillset was far wider than what I was taught. I knew that many tech workers suffer from impostor syndrome (58%, to be accurate), and those first months sure felt like it, but some of it was real — I truly didn’t have the right skills for the job I was hired to do.
Years later, as VP Engineering at a new startup in New York, I witnessed this same problem from a different angle—that of a manager. My resources were limited, so I decided to build my team based on talented yet inexperienced developers fresh out of school. Of course, by then, I’d forgotten that schools teach how to write code rather than how to solve problems. Mentoring my young team became a full-time job, which, while immensely satisfying, was obviously unscalable.
When I did hire experienced developers with whom I could share the mentorship workload, I thought I was finally in the clear. I wasn’t. It quickly became apparent that these devs needed a professional development plan of their own. I couldn’t afford to ignore their needs any more than I could ignore the inexperienced devs, both because I wanted to help them and as I needed to retain them. They knew what skills they wanted to develop, and some had incorporated learning into their daily routine, but theory could only take them so far.
If anything, the professional development challenge grows harder, both for the individual and the company, the more skillful the developer is. Inexperienced developers need to learn pretty much everything, so it’s possible, albeit slow, to accommodate their learning process in line with the roadmap and the tech stack. For experienced developers, the day-to-day creates the boundaries within which they can develop their skills.
Everything I’ve learned during my career as a coder, a developer, and a manager, leads me to believe that there are structural problems with the way our schools and workplaces train new talent and develop (yes, dad jokes are an important skill in our field) experienced developers. As a result, we begin our careers grossly unprepared and find it difficult to continue expanding our skillset as we progress. The sooner developers start working on their senior mindset, the easier it’ll be. Ideally, the development plan begins on the first day of the first job in the industry and doesn’t ever end.
Instead of focusing on coding, we should be paying attention to the many skills a seasoned developer needs to have. In fact, good coding isn’t necessarily the most important part of any job in this industry. Is the ability to maintain a production system more critical? Often, yes. The ability to design from scratch? Of course. People skills? Usually more important than anything else. And all of these skills, hard and soft, cannot be taught just by watching talks on YouTube.
This is what we at Wilco are trying to build. A way for coders to become developers and for developers to become better, hone their skills, adopt a senior mindset and continue their professional development. It’s Continuous Development, but for people—not code.
How will we do that? Stay tuned. And in the meantime (it’s the last pun, I swear)—never stop developing!
Co-Founder @ Wilco