Being faced with maintaining your own code in Production months after moving on and after having forgot about its structure is one of the best learning experiences for a programmer, IMHO.
It’s a great way to learn at an emotional level (through self-inflicted pain and suffering ;) the real point of a lot of good practices that previously looked like “a waste of time” and design principles that before “made no sense”.
Personally that’s one of my requirements when hiring technical types above Junior level.
I’ve rarely actually had much trouble coming back to a project I started / played a large role in after a few months (or even years). I’ve experienced what you describe on other projects though, especially if they’re way outside my field of expertise.
Somewhat off topic, I’m searching for a new job soon - are there any good guides or information on design practices you’d recommend? I’m self taught with no college education, and a majority of the work I’ve done has been for SMBs on (mostly) solo projects where I determine the direction to take. I like the flexibility of working for SMBs, however there are a lot of cons as well. I sometimes worry I’m shooting myself in the foot listing just under a decade of experience, but none of it “junior level on a team” where I’d pick up some of those skills.
Working directly with “the business” (such as end users in an SMB) is actually a highly valuable skill for a programmer, because ultimatelly we’re paid to make the software to be used by normal users as part of their business and people who combine programming skills with (proven, genuine) experience in working directly with users and stakeholders in the business side delivering software for their needs, are quite rare.
This is especially valuable in any large company whose core business is not Tech but makes heavy used of Technology and has custom systems serving their business side, such as, for example, investment banks - the user and business oriented programming areas (not just frontend but basically anything that’s tightly coupled to the nature of the business of the company) value “understanding the business” and “figuring out the software that needs to be done to serve user and the business needs” as much or more than technical proeficiency.
(It’s all nice and neat to, say, be a “guru” who came up with his or own programming language, but actual companies whose actual business needs have nothing to do with programming languages, couldn’t care less, though such techie “chops” definitelly impress young and naive techies)
I don’t think “junior level on a team” matters if you have almost a decade experience - in my experience by that point nobody gives a rat’s arse about what you did as a junior unless it’s something you’ve never done since and are trying to leverage in an interview - but having done projects professionally as part of a team does matter a lot, because big projects can’t be done solo in a reasonable amount of time and hiring manager do want people who have proven they can work well as part of a team. Only way I can see to make up for this if you don’t have it is to participate in larger Open Source projects.
Also being self-directed and capable of working without lots of supervision is highly valued: somebody whose input is “there’s this (non-techie) thing we need solving” and whose output is the implementation of the solution is worth his or her weight in gold, not just in the kind of small company which can’t afford dedicated technical managers (to go around supervising the less self-directed kind of dev) but also in larger companies as it saves lots of time and problems all around when a programer can just take ownership of figuring out the details of the problem and delivering the solution.
Maybe you might’ve been ignoring some of your greatest strengths by looking only at the technical side of your experience.
Wow, thanks - your response offers quite a bit of fresh perspectives and insight I hadn’t considered. Yes, my main pain point was my ability to work on a team - I have done so but not at scale and mostly in the micro-managing kind of way. But I’ve been letting that impact my motivation by a good deal.
I also hadn’t realized being able to convert layman input into usable output was a valuable skill for larger companies, assuming they’d have project managers to handle that. I wonder how difficult it would be to take on a more managerial role - that has been another pain point, I find I get burnt out on large projects fairly fast, but that’s usually me doing all of the heavy lifting.
Thanks for the feedback, I appreciate it. I think I’ll try and revise my resume some and start looking with some fresh perspective.
Well, the whole managers who take client input is a bit of an iffy situation: you see, the whole think suffers from the “chinese wispers” problem (the longer the chain between those who require something and those who implement it, the more the message gets distorted and the implementation is off from the actual requirements).
So not only do companies whose core business is not Tech value more technical people who can talk directly to the business (it keeps the rate of misunderstandings smaller and improves need-to-solution turnaround), but even companies that sell IT services (i.e. consultancies) value more people who understand both the technical side and the client (which are the businesses the work for) side - for example an IT “consultant” from the likes of Accenture needs basically that kind of skillset, as well as some salesmanship.
The ones were that is really not valued at all are the B2C Tech companies (i.e. companies that make products for consumers).
My own experience doing software engineering for Investment Banks is that, at least in the IT area I worked in (mainly the “frontoffice”, which deals with things like providing trading solutions directly to business users such as traders), having both sides was very valuable and in fact frontoffice hiring managers prefer techies who “know the business” (it’s usually an absolute requirement for the more senior techie positions) and was the one that paid the most out of all IT areas in there.
Also don’t forget that the being self-directed is also very important: you might not see that because you’re in smallish companies were people have to wear many hats (i.e. do a bit of everything) and the only the ones who can “sort things out” survive, but in really large companies people are a lot more narrowly focused and when everybody does just a narrow set of things you’ll find a lot more the low initiative kind of programmer who won’t really do even the most basic of self-management and needs to be fed very precise tasks to execute rather than be given a problem and figuring out the rest. Many managers in there do value people who can basically be instructed to “solve this problem” rather than need to be constantly fed instructions.
I can understand the whole burning out if on a large project on your own - personally for me it’s a time thing: by the 2 years mark I start getting bored and looking for new challenges. Fortunatelly projects in bigger companies, because of having a lot more people, even though they’re huge compared to solo developer projects, tend to last around 2-3 years or less and actually most projects are of the “add/adjust functionality on an existing system” kind rather than the so-called “greenfield projects” (i.e. done from scratch) and those are more measured in weeks of a few months.
Being faced with maintaining your own code in Production months after moving on and after having forgot about its structure is one of the best learning experiences for a programmer, IMHO.
It’s a great way to learn at an emotional level (through self-inflicted pain and suffering ;) the real point of a lot of good practices that previously looked like “a waste of time” and design principles that before “made no sense”.
Personally that’s one of my requirements when hiring technical types above Junior level.
I’ve rarely actually had much trouble coming back to a project I started / played a large role in after a few months (or even years). I’ve experienced what you describe on other projects though, especially if they’re way outside my field of expertise.
Somewhat off topic, I’m searching for a new job soon - are there any good guides or information on design practices you’d recommend? I’m self taught with no college education, and a majority of the work I’ve done has been for SMBs on (mostly) solo projects where I determine the direction to take. I like the flexibility of working for SMBs, however there are a lot of cons as well. I sometimes worry I’m shooting myself in the foot listing just under a decade of experience, but none of it “junior level on a team” where I’d pick up some of those skills.
Working directly with “the business” (such as end users in an SMB) is actually a highly valuable skill for a programmer, because ultimatelly we’re paid to make the software to be used by normal users as part of their business and people who combine programming skills with (proven, genuine) experience in working directly with users and stakeholders in the business side delivering software for their needs, are quite rare.
This is especially valuable in any large company whose core business is not Tech but makes heavy used of Technology and has custom systems serving their business side, such as, for example, investment banks - the user and business oriented programming areas (not just frontend but basically anything that’s tightly coupled to the nature of the business of the company) value “understanding the business” and “figuring out the software that needs to be done to serve user and the business needs” as much or more than technical proeficiency.
(It’s all nice and neat to, say, be a “guru” who came up with his or own programming language, but actual companies whose actual business needs have nothing to do with programming languages, couldn’t care less, though such techie “chops” definitelly impress young and naive techies)
I don’t think “junior level on a team” matters if you have almost a decade experience - in my experience by that point nobody gives a rat’s arse about what you did as a junior unless it’s something you’ve never done since and are trying to leverage in an interview - but having done projects professionally as part of a team does matter a lot, because big projects can’t be done solo in a reasonable amount of time and hiring manager do want people who have proven they can work well as part of a team. Only way I can see to make up for this if you don’t have it is to participate in larger Open Source projects.
Also being self-directed and capable of working without lots of supervision is highly valued: somebody whose input is “there’s this (non-techie) thing we need solving” and whose output is the implementation of the solution is worth his or her weight in gold, not just in the kind of small company which can’t afford dedicated technical managers (to go around supervising the less self-directed kind of dev) but also in larger companies as it saves lots of time and problems all around when a programer can just take ownership of figuring out the details of the problem and delivering the solution.
Maybe you might’ve been ignoring some of your greatest strengths by looking only at the technical side of your experience.
Wow, thanks - your response offers quite a bit of fresh perspectives and insight I hadn’t considered. Yes, my main pain point was my ability to work on a team - I have done so but not at scale and mostly in the micro-managing kind of way. But I’ve been letting that impact my motivation by a good deal.
I also hadn’t realized being able to convert layman input into usable output was a valuable skill for larger companies, assuming they’d have project managers to handle that. I wonder how difficult it would be to take on a more managerial role - that has been another pain point, I find I get burnt out on large projects fairly fast, but that’s usually me doing all of the heavy lifting.
Thanks for the feedback, I appreciate it. I think I’ll try and revise my resume some and start looking with some fresh perspective.
Well, the whole managers who take client input is a bit of an iffy situation: you see, the whole think suffers from the “chinese wispers” problem (the longer the chain between those who require something and those who implement it, the more the message gets distorted and the implementation is off from the actual requirements).
So not only do companies whose core business is not Tech value more technical people who can talk directly to the business (it keeps the rate of misunderstandings smaller and improves need-to-solution turnaround), but even companies that sell IT services (i.e. consultancies) value more people who understand both the technical side and the client (which are the businesses the work for) side - for example an IT “consultant” from the likes of Accenture needs basically that kind of skillset, as well as some salesmanship.
The ones were that is really not valued at all are the B2C Tech companies (i.e. companies that make products for consumers).
My own experience doing software engineering for Investment Banks is that, at least in the IT area I worked in (mainly the “frontoffice”, which deals with things like providing trading solutions directly to business users such as traders), having both sides was very valuable and in fact frontoffice hiring managers prefer techies who “know the business” (it’s usually an absolute requirement for the more senior techie positions) and was the one that paid the most out of all IT areas in there.
Also don’t forget that the being self-directed is also very important: you might not see that because you’re in smallish companies were people have to wear many hats (i.e. do a bit of everything) and the only the ones who can “sort things out” survive, but in really large companies people are a lot more narrowly focused and when everybody does just a narrow set of things you’ll find a lot more the low initiative kind of programmer who won’t really do even the most basic of self-management and needs to be fed very precise tasks to execute rather than be given a problem and figuring out the rest. Many managers in there do value people who can basically be instructed to “solve this problem” rather than need to be constantly fed instructions.
I can understand the whole burning out if on a large project on your own - personally for me it’s a time thing: by the 2 years mark I start getting bored and looking for new challenges. Fortunatelly projects in bigger companies, because of having a lot more people, even though they’re huge compared to solo developer projects, tend to last around 2-3 years or less and actually most projects are of the “add/adjust functionality on an existing system” kind rather than the so-called “greenfield projects” (i.e. done from scratch) and those are more measured in weeks of a few months.