Finding a job is hard
Recently, my first contracting job ended rather abruptly. My recruiter had mentioned a couple weeks before the notice that my contract was going to be extended by six months, so I was of the impression that I could take my time finding my next gig. Fortunately, the company gave my a (close to) 30 day notice, so I had some time to prepare for interviewing and all the work that goes with that. 30 days to find a new gig, though, isn't much time when you factor in all the processes that go along with finding and securing a new job.
I saw a statistic recently that said the majority of new jobs are secured through people you know. Working remotely does have the disadvantage of not getting out and seeing/meeting new people, but then again, you'd really only be seeing/meeting the people you work with, which you do the same with remote without the morning ritual of water-cooler/coffee talk. Having worked 100% remote for the last 3 years or so, I'm ready to get into the office again. Sure, the commute may be less favorable (commuting 12 feet to work has its pros and cons, of course) but I miss that ritual of morning pre-work communication, gathering around the watering hole and debriefing and being debriefed on the prior day's goings on. But measuring a commute in feet versus minutes is going to take some getting used to. Maybe I'll have some time to listen to all those podcasts I've queued up over the last couple years.
Finding a job is hard. I'm already of the persuasion that I'm not worthy, but I do go through phases where I feel like I'm not paid enough versus I'm not skilled enough. I tend to gravitate toward the latter more often than not. I suffer from the Imposter Syndrome. I think most of the issue with that is that I tend to compare myself with the upper-echelon in every endeavor in which I choose to participate. This clearly isn't fair, but it helps me strive to be better. The downside is it becomes a bit more obvious what I don't know. But then comes the realization that the more I know, the more I know I don't know, and the cycle just feeds upon itself. Add to that all the technologies there are to learn about these days in the world of software development, and I start to believe that maybe I don't know enough to be in this realm.
Interviewing is all about self-promotion and how awesome I am, and how great it would be if your company hired me. Oh the places you'll see, etc. etc. Feeling like I don't know anything, though, tends to run counter to that sales pitch, so I tend to undersell myself. When I do land the job, however, I'm right back in that vicious cycle vacillating wildly between "I don't get paid enough" and "I don't know enough."
What do I want to be when I grow up? I don't know. I do know that I enjoy solving problems, whether they are virtual (software, for instance) or physical (building something complex from scratch like a CNC machine, for instance). I've worked in several different industries from electronics manufacturing to trucking to banking to insurance. All have their unique problems, and each of those problems can be solved myriad ways. Some of the solutions are better than others, of course, and most of them follow general engineering guidelines.
Software, from what I've seen, isn't yet treated like a true engineering discipline. A lot of bean counters tend to treat software as a commodity and that if you're a software developer, you can do or write whatever kind of software is necessary to get the business problem solved. One of the things I've satirically said in the past is, "It's just software, how hard can it be?"
Software architecture is something I would really like to get better at. Solving difficult problems with elegant solutions - I would love to put something like that on my resume. It takes time, though. It takes a lot of trial and error. Mistakes will be made, etc. etc.
In Robert "Uncle Bob" Martin's Clean Code he mentions the concept of code smells. While this is the first exposure I had to the term, it appears Kent Beck & Martin Fowler (no surprise, I suppose) first coined the term.
The problem I run into a lot is that I tend to get paralysis by analysis. I can see a plethora of different approaches to a given problem, but don't quite have the guts nor background experience to decide on a direction. I definitely want to get better at that, and it appears that Domain Driven Design (DDD) attempts to tackle that problem for more complex systems. I would imaging Test Driven Design (TDD) would pair nicely with DDD for such issues.
Meanwhile, there is more I could learn about C# and JavaScript and Angular and React and Vue and design patterns in general and CSS and HTML and the list goes on. And on. And on. And on. It's one of the aspects of software development that I admired and still do (the immense learning opportunities), but it's a double-edged sword. Companies are looking for those buzzwords. If you don't know those technologies (in some cases the hiring folks want you to know everything inside and out, it seems) then you won't be considered for the position.
However, I feel like having the passion to learn new technologies and learn how they fit together is far more beneficial, both to the person and to the hiring company. Software is running our world, like it or not, and it's scary how fragile some of the systems I've worked on are, given how important they are to our daily livelihood.
So, starting now, I will be learning more about TDD in concert with DDD and focus my attention on learning meta languages: design and architectural patterns. I think that will satisfy my desire to learn, my desire to solve problems, and keep my focused on something that will drive my career forward. I believe these areas of focus transcend technology stacks and are very important to get things done in a way that supports fundamental engineering practices.
I saw a statistic recently that said the majority of new jobs are secured through people you know. Working remotely does have the disadvantage of not getting out and seeing/meeting new people, but then again, you'd really only be seeing/meeting the people you work with, which you do the same with remote without the morning ritual of water-cooler/coffee talk. Having worked 100% remote for the last 3 years or so, I'm ready to get into the office again. Sure, the commute may be less favorable (commuting 12 feet to work has its pros and cons, of course) but I miss that ritual of morning pre-work communication, gathering around the watering hole and debriefing and being debriefed on the prior day's goings on. But measuring a commute in feet versus minutes is going to take some getting used to. Maybe I'll have some time to listen to all those podcasts I've queued up over the last couple years.
Finding a job is hard. I'm already of the persuasion that I'm not worthy, but I do go through phases where I feel like I'm not paid enough versus I'm not skilled enough. I tend to gravitate toward the latter more often than not. I suffer from the Imposter Syndrome. I think most of the issue with that is that I tend to compare myself with the upper-echelon in every endeavor in which I choose to participate. This clearly isn't fair, but it helps me strive to be better. The downside is it becomes a bit more obvious what I don't know. But then comes the realization that the more I know, the more I know I don't know, and the cycle just feeds upon itself. Add to that all the technologies there are to learn about these days in the world of software development, and I start to believe that maybe I don't know enough to be in this realm.
Interviewing is all about self-promotion and how awesome I am, and how great it would be if your company hired me. Oh the places you'll see, etc. etc. Feeling like I don't know anything, though, tends to run counter to that sales pitch, so I tend to undersell myself. When I do land the job, however, I'm right back in that vicious cycle vacillating wildly between "I don't get paid enough" and "I don't know enough."
What do I want to be when I grow up? I don't know. I do know that I enjoy solving problems, whether they are virtual (software, for instance) or physical (building something complex from scratch like a CNC machine, for instance). I've worked in several different industries from electronics manufacturing to trucking to banking to insurance. All have their unique problems, and each of those problems can be solved myriad ways. Some of the solutions are better than others, of course, and most of them follow general engineering guidelines.
Software, from what I've seen, isn't yet treated like a true engineering discipline. A lot of bean counters tend to treat software as a commodity and that if you're a software developer, you can do or write whatever kind of software is necessary to get the business problem solved. One of the things I've satirically said in the past is, "It's just software, how hard can it be?"
Software architecture is something I would really like to get better at. Solving difficult problems with elegant solutions - I would love to put something like that on my resume. It takes time, though. It takes a lot of trial and error. Mistakes will be made, etc. etc.
In Robert "Uncle Bob" Martin's Clean Code he mentions the concept of code smells. While this is the first exposure I had to the term, it appears Kent Beck & Martin Fowler (no surprise, I suppose) first coined the term.
A code smell is a surface indication that usually corresponds to a deeper problem in the system.When you've been around software development for a while, this concept really starts to become ingrained and that gut feeling when you're coding something that's not quite right ends up being a sign that there's a "deeper problem in the system". In my experience, more often than not, it's basically when architecture goes bad.
The problem I run into a lot is that I tend to get paralysis by analysis. I can see a plethora of different approaches to a given problem, but don't quite have the guts nor background experience to decide on a direction. I definitely want to get better at that, and it appears that Domain Driven Design (DDD) attempts to tackle that problem for more complex systems. I would imaging Test Driven Design (TDD) would pair nicely with DDD for such issues.
Meanwhile, there is more I could learn about C# and JavaScript and Angular and React and Vue and design patterns in general and CSS and HTML and the list goes on. And on. And on. And on. It's one of the aspects of software development that I admired and still do (the immense learning opportunities), but it's a double-edged sword. Companies are looking for those buzzwords. If you don't know those technologies (in some cases the hiring folks want you to know everything inside and out, it seems) then you won't be considered for the position.
However, I feel like having the passion to learn new technologies and learn how they fit together is far more beneficial, both to the person and to the hiring company. Software is running our world, like it or not, and it's scary how fragile some of the systems I've worked on are, given how important they are to our daily livelihood.
So, starting now, I will be learning more about TDD in concert with DDD and focus my attention on learning meta languages: design and architectural patterns. I think that will satisfy my desire to learn, my desire to solve problems, and keep my focused on something that will drive my career forward. I believe these areas of focus transcend technology stacks and are very important to get things done in a way that supports fundamental engineering practices.
Comments
Post a Comment