First of all, that I called myself a "software engineer"
From the translator:
We who cut mere stones must always be envisioning cathedrals. We, who cut simple stones, should always see cathedrals behind them. We all remember this wonderful quote from the book by Andrew Hunt “The Pragmatist Programmer. The path from apprentice to master. " The post below, in my opinion, is about this. Its author, technical leader and architect Dave Taubler, talks about how his career and his views on his work in general developed: from disappointment in marketing to what he came to today, many years later. The author shares some recommendations that he considers useful for career development, and, as written in the title, talks about what he would change in his own career if he could.
My career began not in software development, but in marketing. I am a creative person and I thought that the art of slogans and harmonies would suit me. But the marketing world has turned out to be more mechanical than I imagined. Surprisingly (or perhaps not surprisingly) I realized that programming - until that time a hobby - gave me the creative energy I craved. So after a couple of jobs in marketing, I found a job in web development. This job was the beginning of my career as a software engineer, since then I have not returned to marketing.
The profession was great. She paid well, of course, and I kept my job during the economic downturn. Web development allowed me to work with different companies and meet wonderful people. And let's face it, coding is fun, so I have little regret. But there is still something that I regret. Namely:
I would like not to see myself as a "software engineer".
I'm not talking about calling yourself a "programmer" or "software architect" or whatever; specifically these two words don't bother me much. I mean, I’m sorry that I’ve defined my entire professional purpose in life to design software and write code. Why? There are actually several reasons.
I thought of myself as an obstacle to be removed
I used to think of myself as a switch [approx. transl. - of course enabler is "a person or thing that makes something possible": a person or thing that makes something possible. But in this case, the author regretfully speaks of himself as an element of a chain, which means that this kind of literalism is appropriate here, it clearly reflects the mood and intent of what was said], a necessary link in the product development chain that translates concepts into reality. This is as important to business as water is to life. But lately I am not so sure of such self-determination anymore.
Think about how product development works. Someone comes up with a great idea. For example, provide funding to people who cannot get a loan, or help craftsmen sell their work online. But in order to turn an idea into reality, the author of the idea needs someone else who has the experience and skills to make the idea come true. This is where I come in as a software engineer. Just pay me and I will contribute to your idea. Right? Yes. Except for what dawned on me: I'm not really an assistant. I am a hindrance. I am what really stands between the idea and its embodiment. What needs to be removed. In other words: do you think they wantdo people hire someone else to implement ideas? If they could, say, just press a button ... wouldn't they choose a button instead?
Of course, there is no such button. Not yet. But the industry is slowly moving towards it. A long time ago, to make a simple website, you had to hire someone like me. And now, with tools like Wix, almost anyone can drag and drop their way to a fairly advanced site ... No programmer required! Low-code development platforms also reduce the need for software engineers.
Even the programming languages themselves are gradually (albeit slowly) being simplified; writing becomes easier. After all, what is the point of a programming language if not to bridge the gap between human instructions and how the computer executes instructions? Do not misunderstand me. I don't think the demand for software engineers will soon disappear. But ... to provide oneself with skills whose value is gradually decreasing? Such a career began to seem unreliable to me. And that led me to my second problem:
I developed unwarranted cynicism
When I first started out, Java was a hot new product. So I dived into it headlong. And I remember some die-hard C and C ++ programmers who absolutely hated Java. Of course they had reasons. But it seemed to me that these reasons in many cases were simply masking the existential threat that programmers felt. The ability to program came to them with great difficulty. Then came Java, which abstracted away many of the difficulties of C and C ++. Suddenly it turned out that a whole stream of new programmers could do their work.
Fast forward a few years when I began to feel like I was in the shoes of these programmers. Reflexively, I found and accentuated flaws in any language or technology that were supposedly simpler than what I knew. Of course, I had and my reasons for doing this. But often they were more like rationalizations that are created later. So what happened to me? It's been a long time since I took root in my favorite set of programming tools and didn't want to give it up. My goal was not to apply technology to solve problems, but to apply specific software development skills that I had already honed. “If these skills become unnecessary, my goals will not be needed either,” I thought. And so I built a defensive wall out of cynicism. The same one over which in other programmers, many years ago, I wondered.
The point is, maintaining such cynicism can be nerve-wracking and exhausting. In fact, I noticed a vicious circle: the more I defend myself against my own skills, the less I want to learn new things.
I limited my professional horizons
I have worked in many industries throughout my career. Social media, music streaming, financial technology (fintech) and even photo editing. Although I have experience in many industries, I am not always well versed in a particular area. At the same time, I noticed that some of my fellow engineers stayed in the same industry throughout their careers. One colleague, for example, had a passion for photography, so he specialized in photo editing software. Other colleagues have devoted their entire careers to financial technology.
The fact is that, first of all, they were interested in their industries. Programming was simply a means by which my colleagues participated in their industries and made a living.
At first it seemed a little strange to me. If you write code, I wondered, shouldn't you define yourself as a software engineer? Of course, I would make an effort to study any area in which my current company operates. But it often seemed to me that this was a necessary evil and that I should pay more attention to hone my technical skills. So why does it matter? Of course, many engineers have enjoyed successful careers focusing almost exclusively on software and technology, haven't they?
Career growth
In hindsight, I realized that part of the problem was how I thought. When I thought about my role at work as a programmer, I tended to just agree. Other people know the business , I have defined for myself, and therefore they can prioritize my team's work . I was in the company just to do my job. While concentrating on software development, it rarely occurred to me that I had higher aspirations.
But to go beyond the role of a senior engineer, we need to understand the business. Regardless of whether we are following the Manager / Director or Chief Engineer / Architect route, we will begin to make high-level decisions on behalf of the company. Understandably, when I first took up a leadership position, I was uncomfortable focusing on business issues. But when I got used to thinking on behalf of the business, I felt free. It was like discovering a whole new set of skills. If you aim even higher, the focus is even more on the business. The experience of engineers in the industry is becoming vital. And what about those colleagues of mine I told you about? Many of them left the engineering world entirely and got promoted in business. Some later left to found their startups in financial technology.
Career happiness
As much as I enjoy coding, I found it difficult to maintain a passion for writing code day after day. To be truly happy in your career, it is important to know, it is important to see the big picture of how my work is changing the world for the better.
Moreover, I would like to do what some of my colleagues have done, which is to take a step back and understand what I truly value in this world. A lot is important to me: music, education, climate change, etc. If I could go back and change something in my career, this is what I would change: I would decide what my values are and what problems I want to solve in this world. And then I would apply all my skills, technical and non-technical, to solve these problems.
How to go beyond software engineering
This story may not resonate with everyone who writes software to make a living. There are many readers who love their industry more than their programming language. Who is comfortable enough jumping from C # to JavaScript and from there to Go. Who without problems gives up what he has already learned when the solution appears easier. But if this story resonates with you, read on. Over time, I have changed my attitude towards my career, and there is no reason why you cannot do the same. Below are some tips that I find helpful.
Dive into other technologies
What will cure our reluctance to part with the technology we are used to and rely on? Immersion in other technologies. The easiest way to do this dive is in a side project: the software that we create ourselves when working hours are over. The main thing is to dive deeply into a language unfamiliar to us. I'm talking about two things:
- Choosing a completely different language outside of our comfort zone. For example, if you're comfortable with Java, don't just switch to Kotlin; try Go, Python, Rust or NodeJS instead.
- On the definition of the complex in the sense of completing the project Don't just work with the tutorial. Set a lofty goal for yourself that will make you really learn the language in order to achieve it.
Indeed, make it your goal to learn a new language so well that you can get a job with that language for money. I did just that many years ago. I was a software architect focused on the Java backend. But as a side project, I helped a friend build an iOS app and a Mac desktop app. This gave me the skills to later join a well-known music streaming company to help them build an iOS app.
You need more than just different programming languages: you need to dive into tools that are language agnostic. For example, I got my hands dirty as much as possible in Docker and Kubernetes. As I got better and better at unfolding and orchestrating images, I became less concerned about what was in those images.
Or let's take cloud technologies. In the past, I played down the role of serverless technologies because I had no experience with them. But for the last time I have embraced them too. For example, in a recent work, I tried to implement AWS Lambda in our microservices architecture. And worked on a side project where GCP Cloud Functions are widely used.
The more I immersed myself in new technologies, the more liberated I felt. I no longer felt obligated to certain skills, but I felt more flexibility and preparedness to solve problems using the most appropriate tools available.
Focus on the big picture of the design
Like many software engineers, I started to pay less attention to practical programming and more focused on general problems. Managing other engineers and focusing on architecture helped me get rid of my personal time investing in some of the technologies the team was using. In addition, this approach makes it possible to focus on other areas of the business. I was recently part of a cross-functional team that spearheaded a new product initiative. That being said, I spent more time working with product managers and designers who were involved in product development than working with code.
A little caveat. As the head of the engineering department, it is always important for me not to lose sight of the technologies that the team uses, to be aware at least a little. Of course, our team may wish to use languages and tools that go beyond your personal skills. It's not bad; rather, it's a great chance to learn from the team. And trust me, the team will love it if we give them the opportunity to teach us something.
Become an Idea Man
Earlier, I presented a simplified view of how products are born. Someone has an idea, and someone else implements it. So I thought: what to be a developer, why not become an author of an idea?
Side projects
So far, the goal of my side projects has been to either keep up with my existing engineering skills or learn new technologies. In essence, these projects constituted the glorified Hello World exercises.
Now I start with the idea itself. I come up with something that I think will be useful, but ideally will be something new. Sometimes it's an idea that can turn into a product. In other cases, this idea is only useful to me. The point is that I focus primarily on the idea.
Then I challenge myself to find the best way to bring that idea to life. Perhaps the implementation is related to writing a monolithic application in Java. Or maybe it's a JavaScript / React frontend, supported primarily by cloud services, and tied together with a bit of Go code. Maybe we are talking about tasks that are not related to programming at all.
At work
I also began to exercise this common sense at work. Once upon a time, I was looking for projects in which I could use my specific programming skills. After all, I was hired for these special skills, right? But gradually I realized that I was hired primarily to solve the problems of the organization. Therefore, I began to look for the problems that most needed a solution, and I figured out how to solve them. In many cases, the solution is software related. But I began to enjoy the times when the decision was not software-related, because in those days I was expanding my scope and crossing boundaries, focusing more on the business side of things.
Is this easier said than done? May be. Of course, this depends on the willingness of our employer to give up programming at a very fast pace. But I have found that many companies are more than happy when engineers want to take the initiative to solve problems that go beyond the realm of writing software. What if our company does not support the initiative? Then remember that we are software engineers ... We can afford to be a little picky about who we work for.
If you want to dive into other technologies, as the author of the post advises, then we, for our part, are ready to help with this with our knowledge, experienced mentors and support. It will be difficult, but interesting. And do not forget about the always active promo code HABR - which will add 10% to the discount on the banner.
Other professions and courses
