I disagree with these being red flags. In fact, for me, some of them are indicators of gold:
Two Month Contract
That's music to my ears. It signals two important things: First, it's a real contract and thus going to pay really well. Fake contracts present themselves as "contract to hire" or similar so that that they can convince you to agree to a rate of "half your salary, but paid hourly without benefits". But for two months? You're going to hear about my five figure per week rate.
And it's short. Two months and I'm out of there short. So no matter how toxic the environment and how terrible the codebase is, it makes no difference. A guy can stand anything for a couple months. Especially in combination with that first point, which means that this is possibly the only gig I'll need to take all year.
Cold Fusion
Oh yeah, bring it on. This translates as "You are possibly the only person on the planet who knows how to do this work. Charge us accordingly." If you find this in combination with one of the short gigs from above, your life is about to get really good. Your only real problem will be keeping a straight face when you quote the rate you're going to charge for this contract.
In the end, I think it comes down to what you're looking to get out of the job in question. If, like the author seems to be, you're looking for a long term career at a new company then no, you're right, run away from these places.
But if you fancy a bit of fun quick contracting, this article is mostly a list of bill rate multipliers.
Fully agree, a two month contract is music in my ears! Two months focused work with no feelings attached to the project, the people, the technology used there, etc, a really good pay for my work and afterwards 4 months off to South East Asia for surfing, sunshine and Pina coladas. As someone who refuses to take any permanent full time work these gigs are the best!
Totally agree with your points here. I think it's also great to start with a short-term contract before deciding if you want to become a full-time employee. Just like how people usually date for a while before getting married. Becoming an employee is a big commitment, especially at early-stage startups.
(I'm currently looking for a 1-2 month contract if anyone is looking for a full-stack web/mobile developer. Experience with Rails, React, React Native, TypeScript, AWS.)
That's true, but it can be a lot of work to set up a new employee with benefits, stock options. Also maybe there's a signing bonus, a new laptop and other office equipment, relocation, visa sponsorship, etc.
I think it's better to start as an independent contractor (and work remotely.) Then there is the expectation that this is a short-term contract, unless everyone is happy and wants to continue working together.
To be fair to the original poster, it is a post about work for junior devs so they are not likely to be able to charge high rates for obscure contracts
Agree. My last Coldfusion contract rate was good, better than the .Net guys. I've had the same for Teamsite contracts: name your fee and which 5 star hotel you want to stay in.
As I read the article I really feel the authors intention and I share his opinion because I love my craftsmanship and want to develop deep feelings with the product.
As I read your answer I also understand your point and I agree too in case of short contracts. Thanks for sharing your view!
Its probably going to take a month to get familiar with the code base if it has enough complexity. Most companies aren't all that good about documentation.
I've never understood where this sentiment comes from. I drop into a lot of unfamiliar codebases as a contractor, and I'm always fixing bugs and making meaningful contributions on day one.
Speaking and working with other consultant folk, my experience doesn't seem unusual. I haven't experienced first hand this concept of a new hire who is unable to contribute for an entire month. But I do see this sort of comment from time to time, so it must be a real thing somewhere.
It's not about the codebase but the business rules.
I was once handed an insurance codebase and a list of open bugs after the maintainer left on short notice. I fixed a few bugs, which led to more bugs being opened from users in other states. WTF?
Turned out that the business rules naturally varied per state regulator but had never been implemented. Just wading into code would never have resolved that. It took months to compile the documentation before touching yhe code again.
You can't make meaningful contributions on Day One in any regulated industry. Especially as a contractor where the fines might be passed along...
Exactly. It's not so much the technical knowledge as it is the domain knowledge.
So "fixing bugs" and "making meaningful contributions" is a lot easier if you only focus on syntax and not on what the software should achieve in the real world.
If you can run it. I’ve been asked to fix bugs in code that nobody knows how to run or even compile... there’s one copy running in production that somebody deployed a year ago.
I used to work at two different programming jobs where people commonly said you weren't really useful until you'd been there multiple years. In both cases I agreed.
I don't even think I have finished signing papers doing the mandatory training etc. getting my computer accounts etc. on day 1, but I have always been a full time employee.
Red flag for outdated technology? That is hilarious. The IT world has already more work in maintenance than in greenfield projects and that will grow every day. When that is a red flag, good luck finding work in future.
"Companies advertising outdated stacks open you up to the risk of building the wrong sorts of skills, which can have far-reaching effects on your career." (Emphasis mine.)
The wrong sort of skills? Like adaptability, strong diagnostic skills, pragmatism, self-awareness, and not being a massive diva all the time? Although it's true that these things can have a far-reaching effect on your career.
Every company that's been around for a while has legacy code and you need to lose the fear of working with it. You also need to develop enough humility to realise that the code you're writing today is tomorrow's legacy.
Having code that's lasted long enough to need maintenance is a sign the company has at least some grounded-in-reality fundamentals. The projects that fell apart upon learning the business model was untenable or the technical or social problem insurmountable, generally don't need maintenance programmers.
Staying a little off the bleeding edge also lets you focus on quality execution, rather than chasing the trends. Sometimes the eventual best practices aren't even offered and understood if you're adopting a platform or framework too early. Nobody wants to hit a "drop everything and rewrite because there was a huge API shift" moment.
Nobody wants to hit a "drop everything and rewrite because there was a huge API shift" moment.
No business owner or manager wants that. I know lots of programmers for whom any excuse to throw away everything and rewrite from scratch is basically Christmas. Some of the more unscrupulous ones might even try to engineer unnecessary excuses to do just that.
Oh, I’ve seen executive leadership fall for unscrupulous/ignorant consultants pitching a “burn your stack, move everything to the cloud/LCNC/SaaS, and fire your developers” approach. Invariably either the company or the CEO’s tenure expires.
Yeah, it’s the inherent tension between wanting a client that knows they’re in a crisis, and the fact that companies in a crisis might not be able to pay you. Yes, they’re ready to make the hard decisions; no, they might not have the financial and operational latitude to actually do so.
I think maintenance may be growing on me, but making a judgement on whether it's a good thing is certainly multivariate.
While high turnover is almost always bad, low turnover on legacy projects might mean that critical parts of the infrastructure have been locked up by ideologues. It's not automatically bad but you should very certainly ask some pointed questions in this area. A yellow flag, if you will.
I once took a personality test. One part of it corresponded to product lifecycle: 1 was initial conception, 2 was prototype, 3 was roll-out, 4 was major enhancement, and 5 was maintenance. My personality is that I prefer prototype to roll-out. (In initial conception, there's too much uncertainty for my taste - everything is possible, but nothing is nailed down. And maintenance is boring.)
My point: You don't have to give a rational explanation of why you prefer maintenance. You can do so from your perspective, but it won't translate to those who, due to their personality, prefer other phases.
But if you want to say that projects that made it to maintenance should have money available to pay you, then yeah, you've got a point that transcends personality...
I think it depends on the developer's focus. The project I maintain was written by people who were network programming enthusiasts, so it has a number of different TCP-based transports, some of which are no longer maintained. It's made updating TLS a pain.
Yeah, this is weird. I feel like it's talking about specializing in a math subsubdiscipline, or surgery on a particular piping of a particular model of Soviet-era rocket engine.
Tech stacks aren't that hard. Especially when it comes to web frameworks. To me, maintaining legacy stuff in legacy technologies requires primarily grit - the ability and patience to wade through unique and idiosyncratic mess with a debugger and come out alive on the other end. The fundamental skills of a developer, and even the fundamental technical challenges, don't change that much between frameworks or even programming languages.
The primary danger of being in legacy tech to me is having wrong keywords on your CV and getting auto-filtered when applying for a new job. I know businesses would love to immediately hire experts in their particular tech stack, but let's not kid ourselves - the stacks are trivial compared to learning the processes and code at a particular business. I don't see why a competent Angular developer wouldn't be able to pick up React in the inter-job period to the level comparable with what that person with "React" on their CV has.
Assuming what I wrote above is true, then note that hacking around outdated CV keywords is a much different problem than mitigating those "wrong sorts of skills" working with non-fad tech would hypothetically give you.
> let's not kid ourselves - the stacks are trivial compared to learning the processes and code at a particular business.
True. We're primarily a .NET/TypeScript/React/SQL Server shop but I'm happy to consider anyone with some experience of a C-like language, and some web development experience - it's also not necessary for these things to overlap. Beyond that, if you know what a database (of any sort) is I'm basically happy.
It's hard enough to find people who can program well in any language without making life even more difficult for yourself by adding requirements for N years experience in a given framework or technology.
I call this having "Complimentary" skill sets. If an OO shop, Java vs .NET and Ruby/Python etc. Hire for smart, ambitious, willing candidates that fit in well with the culture. I've seen people switch tech stacks very quickly, especially when there's established patterns in the existing code base they can pick up on.
I think programming language/tech stack is about 8th on my list of deciding on where to work, etc. (This just inspired me to do some writing on the subject, since I've delivered systems in most major tech stacks over the years.)
> The wrong sort of skills? Like adaptability, strong diagnostic skills, pragmatism, self-awareness, and not being a massive diva all the time?
Yes, the wrong set of skills. If the market is looking for, say, React devs then you'd be a fool to accept a job where you are expected to work with, say, Delphi or AS400. Yes, maintenance jobs working on old established services are enough to make a living and even a profitable one, but let's not fool ourselves into believing that your odds of being the top candidate in today's or tomorrow's high-profile projects will be greater if you waste your time in outdated stacks.
The market? What market? There's more than one. There's a market for React devs, and there's a market for COBOL devs. You look at the React market, and you see that it's growing. But so is the pool of React devs. The market for COBOL devs may be shrinking, but the pool of COBOL devs may be shrinking faster. Which is the better career choice?
And why do I care about being a candidate for a high-profile project? Pay? Yes, there can be good pay - along with lousy work-life balance. To steal a line from Agassiz, I cannot afford to waste all my time making money.
And why is an out-dated stack "wasting my time"? Do you have a utility function for my time? I deny the validity of it. I would say that chasing a high-profile project in React is almost certainly wasting my time.
Yep you're right as much as I wish it wasn't the case, if two candidates were identical except one had skills in cutting edge technology and the other had skills in older tech I would pick the newer
May just be the business we're in but I feel going with the old limits your breadth (but maybe with a higher price tag? COBOL?)
You wouldn't choose a top-tier React & AWS dev if your veteran Cobol dev had just died of old age and your business-critical Cobol & SAP monstrosity needs urgent changes to handle this years's tax compliance updates. In that situation, you'll pay the $20000/week or whatever oaiey quotes you.
All right, so maybe you feel bad now about not listening to the engineering team and maintaining a continuous migration of your business-critical code to modern platforms over the last 30 years. But that's all in the past and your million-dollar business will be shuttered by the tax authorities in three months if you don't get this sorted out right now.
Maybe we'll have a world one day where everyone knows the "obvious" fact of technology leadership that everything should be continuously migrated to the state of the art. But maybe we won't, and maybe this fact isn't obvious at all, or even correct. Who knows?
In the meantime, people with skills that have an extreme demand/supply factor can command the highest rates, even if they won't be hired at tomorrow's startup. That's not to say it's a bad idea to learn current skills (for diversification), and definitely say no to working with legacy tech for small money, but that's really an orthogonal point to the one oaiey was making.
> In that situation, you'll pay the $20000/week or whatever oaiey quotes you.
I looked into this recently, because I wanted to see if it would be worth learning COBOL to help maintain old banking systems. Unfortunately the pay is nowhere near $20000 / week, and experienced COBOL programmers typically make around $100 per hour, or $70k per year at a full-time job. Right now you can make much more money with modern web and mobile development.
I was surprised to hear it was only $100/hr, but some people say it might go up to $1000/hr, and one person was making "high six figures". So I don't know. Maybe it's worth getting into if you have some good connections.
I hire about 150 COBOL guys and gals (as full time employees) and they are making in average 100k€ (European Bank) incl. 1 month holiday.
Big brand contractors cost us around the same.
DBAs, Sys Admins, operators, a bit more.
Having 30y experience myself, from mobile and Java to Mainframe Assembler, I find the older guys - both on mobile (few) and COBOL (most) to be much more focus on engineering a system that lasts whatever you throw at them, while (most, not all) young coders are about speed and hashing something together that works (but needs overhaul after 3-4 years).
Just my own experience, not saying is the only perspective.
> I find the older guys - both on mobile (few) and COBOL (most) to be much more focus on engineering a system that lasts whatever you throw at them, while (most, not all) young coders are about speed and hashing something together that works (but needs overhaul after 3-4 years).
I've noticed that tendency in younger developers too and it's utterly infuriating. Do you do anything to discourage this and, if so, what?
Not the person to whom you replied, but: mentorship. Code review. Talk about means, not just ends.
I was fortunate to be a young developer with a desire to write things that could last, so I skipped a few steps and found myself doing the mentoring perhaps sooner than most, but instilling the notion that this thing needs to continue to function, and rejecting work that isn't in service of that goal, is doable.
> Yes, the wrong set of skills. If the market is looking for, say, React devs then you'd be a fool to accept a job where you are expected to work with, say, Delphi or AS400
Only if you expect to leave that company in the next few years like an SV-style webdev. Some of us like the stability of working for an organization where employment time is measured in decades.
Honest questions: what has that stability done for your career earnings? And what does that do when your boss decides you aren't needed anymore?
I ask because I tend to find that we are generally incentivized both to stay on the leading edge and to, if not running a consultancy, to be regularly moving on to new positions. And it is rare, to the point of IMO barely worth considering as a possibility, to find a company that won't get rid of you given half a chance if it makes short-term numbers better.
If your goal is to make as much money as possible, then you probably have to live in that mutually predatory environment, but if your goal is to have a more stress-free existence and feel like your work is actually helping people then there are alternatives.
I have little fear of being laid off at my company because they didn't even lay anyone off during the last recession. It isn't publicly traded, and has a very flat managerial structure, so the typical 80s-guy bullshit doesn't really fly here. We don't make software and get our revenue from selling ad space, we make real things for real people and we charge real money for them.
> but if your goal is to have a more stress-free existence and feel like your work is actually helping people then there are alternatives.
I've interviewed devs with over a decade of experience who clearly opted for a stress-free existence feeling like their work was actually helping people, and now here they are in their mid-40s looking for a job with an obsolete skillset and an obvious track record of not adapting to changes.
It's great that you lead a stress-free life in your 20s and 30s, but how do you expect to cope with the problem of being obsolete and useless and no better than a 20yo fresh out of college (and in some regards far worse) when you reach your 40s and 50s?
When I see someone's resume who jumps from engagement to engagement I usually sort them out. Not a good sign. They learn on my cost and jump as soon as responsibility kicks in. These people have to make career somewhere else.
I mean, that's fine, but you also kinda gotta understand that that is exactly what the industry rewards. If somebody's there longer than two years, there is a very real chance that they have passed up at least one significant salary bump (up to a point, of course, it doesn't continue forever).
If you're offering 10%-a-year raises, etc., what you're saying makes sense to me, but otherwise people are going to leave because it's stupid and self-harming not to.
This isn't an experiment that can be run both ways, but I find it seems to work. I've been here 13.5 years, starting from about 5 years of prior experience. Increases are irregular, but look to be about 7.3% compounded per year. Note that the earliest years of my career are excluded, which is when you'd expect to see the largest increase.
I've never seen layoffs. A person who regularly moves on is quite undesirable, because they would leave before being useful. It typically takes a year before we can really put somebody to use, and two years isn't uncommon.
Yup. My last job was at a large corp and one of my previous managers was in his late 50's, having been there since he graduated college. He was a bit of an exception, but we had many people in their 60's & 70's who had been there for decades.
Both major organizations I've worked in have had ridiculously low turn over and everyone I talked to in both had the assumptions of everyone being lifers. I only left the first because I was tired of doing maintenance on old technology and wanted to experience new dev.
I agree that maintenance shouldn’t be feared but you do need to be cognizant of the risks of being shoehorned. If you’re “the cold fusion expert” this will probably not be rewarded by chances to work with new things (or often even the replacement for that CF system) because they probably have a long backlog of things you can do faster than anyone else. If it pays well, that has upsides but only as long as that system is around: you shouldn’t assume loyalty when they replace it and it’s definitely cause for concern if nobody else in the area is hiring for those skills since you’re one corporate restructure, merger, bankruptcy, etc. away from having to retrain in a hurry.
I think this is also a good area to contrast the two things listed: tons of places have jQuery, it’s still actively developed, and it’s relatively straightforward to replace incrementally whereas CF is proprietary orphan-ware prudent shops have been migrating away from since the late 90s, when it became apparent that they were only indifferently supporting it, so you’re one unpatched bug or Adobe management whim away from a messy forced migration.
I'm not sure the OP was so much fearful of working with legacy code, but rather fearful of corrupting the resume to the point it makes you un-marketable as a programmer.
When making hiring decisions many organisations put great emphasis on the specific skill sets detailed in the resume.
As such it can become dangerous if you end up with a resume dominated with legacy coding skills.
There's always another side. Some programs only need maintenance because they work very well and provide a great deal of value to the company. Others only need maintenance because the organization that develops it is chronically underfunded, can't attract skilled developers, and/or is led by incompetent management, so it needs so much maintenance that it almost all they can afford to do anymore.
The former kind of project teaches you valuable lesson. The latter, however, teaches you skills of dubious value, such as NIH-driven development, playing political games to deflect bugs on other teams, and dealing with bugs in dubious ways (stuff I've seen: detecting corrupted writes to flash devices and correcting them by re-writing corrupted sections until all writes operations are successful).
Thing is, if you do this stuff for too long, your mastery of skills that you need to work in healthy organizations tend to decline.
If you work in web technologies, you can absolutely damage your career prospects by spending 3+ years in legacy technology. I've seen many many of my peers fall behind thinking that way and are now working in roles related to, but not directly involved in software development.
That is just the reality of the web if you live in a high wage country. There is very little legacy work in web technology that is not outsourced.
That is not exactly a career then. You will only be an expert in a trendy technology. I expect a real senior software engineer to be above the newest trend. I do not want him to understand react. I want him to understand the reactive UI concept (which is applied in React, Angular and maybe a 30 year old tech). I expect him to be capable of learning the newest trend within days and also expect him to understand the 40 year old language and the code style written then. All of that, I do not find in someone who burns himself to become an expert in a trendy tech every 3 months.
It depends greatly on what you are doing. I've been coding in React for years now, but I _still_ use concepts I learned from Ember, Angular(1), and even non-web tech. Its all UI programming and in the end they all share much more than you'd think. These days I find I can take one glance at newer stuff (say, react hooks) and start getting ideas about how its used, benefits / limitations, even how its implemented, without spending more than 5 minutes looking at it.
Relatedly, constantly jumping into new stuff can actually _hurt_ your progression because if you never master existing tech (find its limits, reading its source), you'll have more trouble seeing the relationships and trade-off's of the new stuff, and spend way too much time just learning API's without gaining any intuition.
Angular 1 absolutely is legacy code. My current task is removing all the angular code from our app because the last security test flagged it as a severe issue due to out dated libraries.
But the task is to remove the Angular and replace it with something current. List the job on your resume under "something current" rather than Angular, and you're good.
Until jobs doing maintenance pay as well or better and have better career prospects than jobs doing greenfield development, the rational choice is to avoid jobs where you don't get to use the latest fad technology. Being the greybeard that keeps the legacy stuff running is an honorable position, but these people usually have a hard time keeping their jobs when the legacy tech is finally replaced.
All your banking transactions run over old mainframes using COBOL. Probably on systems maintained for 20 years. They will not even be replaced as most already have tried this and not succeeded.
I know of companies training COBOL developers to make sure they can maintain these legacy systems. Mostly they are also the mission critical systems.
The web applications at these financial institutions will be in more modern crappy frameworks. But rest assured the expert COBOL developer gets paid much more for doing a lot less :)
Sure, but what prospects will those newly minted COBOL developers have when the next recession hits and their department decides most of them aren't that critical after all or when they realize they're in a dead-end job and want to move on? The market for mainframe programmers is small and getting smaller every day. There are no new customers in that market, only the existing ones and the list keeps getting shorter every year. The situation is even worse for anyone stuck on legacy tech from the PC era on.
The department cannot get rid of mission critical maintenance. If you do that, your company dies right there and then once you're even minimally unlucky.
The newcomers have a delay where they need to be trained, which is typically measured at at least a year.
The new guys get removed first. Ones working on shiny less critical processes. Shiny and critical generally happens in startups.
When legacy is being replaced, old timers generally see the writing on the wall and move on as well as retrain.
Agreed. I liken it to the natural world where a species can be extremely specialized to exploit a particular ecological niche, but that niche is getting destroyed. Times are good when you're the only animal that can get to a particular fruit but when that fruit goes extinct, you're screwed.
Maybe as if you're one of the very best COBOL programmers around and work as a consultant. However, anecdotally, working a normal 9-5 COBOL programming job at a bank or insurance company doesn't pay well at all.
Some niches are of course different from the mainstream, but spending five years maintaining a VB6 application is unlikely to further your career a lot.
My last contract was both 60 days and involved working on a VB6 application that hadn't had a commit to the codebase for 14 years - and honestly, if that company offered me a full time role I'd seriously consider it.
Working for a short time on an outdated technology is not necessarily a red flag.
Nevertheless, jQuery might support very vital business processes, saves the lifes of hundreds people a day (literally) or Incorporated in something which creates millions every second.
The most crap but working technology might be in places which earn money.
Using jQuery is not a career hazard, the web is html, css and javascript. I don't tell my clients that I do React, I tell them that I solve their business problems.
Empires are built on top of old, ugly, or niche technologies.
You might have more job opportunities with the latest and hottest tech, but you will have far less competition with legacy ones. And you can have a long and successful career with them.
If anything I would consider a red flag to have proprietary or in-house stacks. Those could damage your career by employer lock-in, where your build expertise in tech only used in that company, thus reducing your marketability.
My favorite is always when the job description includes superfluous descriptors in front of the developer role. Like "Rock Star" Developer or "Super Star" Developer. In my experience, it's almost always code for we want to put a ton of responsibility on you, while at the same time having unreasonable expectations for both speed and quality of what you produce.
I always wonder which part of the "Rock Star" personality those companies are looking for. Shooting Heroin at work? Throwing TVs out the window? Chasing teenage groupies? Dressing outrageously?
We sort of hired one. Would you count industrial metal, alternative metal, or nu metal? He had a song that was nominated for a Billboard Music Award.
So far, he has behaved well. We got him using a normal computer keyboard. This is better for software development than the keyboard he had in the band.
Seriously, such a good idea. Esoteric languages are fun, but an esoteric language that gives you the practical ability to stick it to these ridiculous job ad descriptions? That's just legendary.
> In my experience, it's almost always code for we want to put a ton of responsibility on you, while at the same time having unreasonable expectations for both speed and quality of what you produce.
If you want to hire me as a 10x programmer, and pay me 10x the regular programmer salary, I'm all for it :-)
Constantly recycled job openings - to spot this you need to be searching for a few months. But if you notice that the same posting is ALWAYS up for senior positions, and it's not a huge company, your resume has a huge chance of never being seen. From my experience, it's likely a company fishing for H1B applicants. Even if you're on a visa stay away.
No intern program - as a general rule, companies with best engineers scoop many straight out of school. I have never worked at a company with top notch engineering that didn't have an intern program. Sometimes this is hard to see since they focus on certain schools, you may be able to find out from recruiters or Glassdoor.
Heavy usage of third party recruiters - the best jobs are easy to advertise. Either the company is incompetent, the position is for legacy work, or the company is just unnapealing in other ways. If legacy work is your jam, go for it, otherwise be cautious. Note that this does not apply for specialized or very high level positions. Use of executive recruiters is normal since paying the cut is worthwhile.
Low or no bonus - we're in a tech boom nearing 90's levels. Your bonus should be 10-30% of your salary. If the company is public, you need stocks. This is the primary way companies keep apparent wages low. The golden eggs are hidden in bonuses, perks, generous vacation policies, and especially public company stock.
Old school practices - occasional work from home, somewhat flexible hours, casual work environment, free snacks. If they offer less than 3/4 you can find a better gig.
Non technical management - this should speak for itself. I've done it before to much regret.
Strange hiring practices - personality tests, panel interviews, minimum GPA rules, leetcode, asking about personal life (married? Kids? Political views?). If you like the idea of hanging out with people from MENSA, sitting in countless committee style meetings, or next to some frat bros or guys wearing MAGA hats maybe this is for you. But asking these things of you reflects the values of the organization. Birds of a feather flock together and humans are no different.
Find a place with engineers that seem to love what they're doing, eachother, and writing code. If they invite you to lunch and everyone is chatting like old friends you probably can't go wrong. Bonus if they're actually excited to talk to you about technology and what they work on.
There's much more but I'm sure the comment section will be flooded with it :)
"Non technical management - this should speak for itself. I've done it before to much regret."
I wouldn't put this as a con, I've seen lots of engineers turn into terrible managers, because the skills are completely orthogonal, they also then lose touch with the tech - because that's what happens if you stop coding for even a few months.
Vice versa, I've worked with lots of good non technical managers, who respect and defer to you for technical decisions, planning etc
And of course the other way round, also seen good technical managers and bad non technical ones.
In summary, technical experience of a manager is not an indicator for me, what is are the human factors, do they micromanage? Are they happy to cede control and delegate? Do they give realistic deadlines instead of death marches?
The ways engineers are terrible managers non-technical managers are often terrible too. In addition to that, they also know less about work itself and are more likely to be insecure about that. They cant distinguish between good and bad engineers replacing various signals for that and are easy to manipulate by charismatic but not too good engineers. The lack of knowledge shows up in small things and big things and overall bluffing. So you get same problems plus some more.
Non technical here does not mean "does not have technical school". If that person took effort to learn, then he can be technical without degree etc obviously.
"The ways engineers are terrible managers non-technical managers are often terrible too. In addition to that, they also know less about work itself and are more likely to be insecure about that."
I would put that as another human/personal trait, the ability to openly acknowledge ones limitations and delegate/defer when someone else has more expertise than you. For example, when making a technical decision, deferring to the tech lead & individual contributors.
If anything, a technical manager whose tech skills are/have slipped away is more likely to be insecure than someone non technical.
Technical manager needs to defer decisions too. No amount of knowledge makes it good idea to micromanage or not to build consensus with those he manages.
However, he still have better ability in deciding who to defer/trust to, better sense on bullshit vs reality, better idea about nuances of decisions and knows words people use. That shows up in how meetings are moderated, people know it and also some will always try to game the manager. Non technical manager is reduced to parroting sentences and attitudes he does not understand fully. Knowing something is not a disadvantage, ever. Not knowing something is.
Every manager needs to make some decisions too. And in there, knowledge helps. Knowledge that slipped away is better then no knowledge and worst then relevant knowledge.
If you see a small company with the same opening for a long time, it may also be that they just haven't found anyone yet. Recruiting is hard, and it may take a year to fill a position.
Of course, "small company" seems to be red flag for a lot of developers anyway...
The team I'm on has a hiring rate of less than one person per year, but I can't recall anyone ever turning down an offer because we couldn't offer enough money. We're not in Silicon Valley and finding the right talent is just that difficult.
If the small company grows smaller every day and it's all the demotivated developers fault.
Also offering a software service with lots of traveling until we can build The Product. If they are afraid of risk and play it safe today, the best product concept in the world won't change that.
Also superficial company culture, that looks incredible and thats all there is.
If the Company has a linear mindset in a exponential field.
Asking about marital status or number of kids isn't just a red flag. The Equal Opportunity Employment Commission often views it as evidence of illegal hiring discrimination.
If they're asking questions like that, what they're really asking is how available you are to work tons of extra hours, nights, and weekends.
> Low or no bonus - we're in a tech boom nearing 90's levels. Your bonus should be 10-30% of your salary. If the company is public, you need stocks. This is the primary way companies keep apparent wages low. The golden eggs are hidden in bonuses, perks, generous vacation policies, and especially public company stock.
For better or worse, this alone eliminates over half the positions available.
> Strange hiring practices - [...] asking about personal life ([...] Political views?). If you like the idea of [...] sitting [...] next to some frat bros or guys wearing MAGA hats maybe this is for you.
Can you elaborate on that a bit?
I'm not in SV/US, but my impression is that most tech companies are intolerant of different political views and biased against conservatives, so likely you should be targeting companies companies that ask for your political views, if you don't like sitting next to MAGA hat wearing guys.
1 was always caused by the requirements being made by HR.
4 is caused by people wanting to learn things on the employer's dime.
If employers weren't so cheap with training budgets, employees wouldn't do learning projects that end up in Production... wanna see a dangerous company? Find a place that has 37 different technologies in their hiring ads.
> Find a place that has 37 different technologies in their hiring ads.
If those 37 different technologies were all recent (or recently outdated) JS frameworks, or tools that are "hot" right now, I'd want to stay away. But if those 37 different technologies are a mix of tried-and-true pragmatic hacker's choice - say Bash, Perl, Python, R, etc. - covering a bunch of different problem domains, I'd think highly of the company that seems to be able to use the right tool for a job.
This. While not 37, the projects I work on, on any given sprint I can be doing some combination of C#, Python, C++(oooold C++), Java, JavaScript, Perl, BASH or PowerShell. I actually love it because I am not doing the same old thing day in and day out.
While 2 months is short, if you don't want short(ish) term contracts of six to twelve months, awesome. Leaves more for me.
I've got around 18 years experience in a variety of tech stacks, being a contractor/consultant is great. Come on board, either create a brand new piece for the client or help them with an existing problem, deliver, move on.
God save me from rotting away in a corner at some huge corporate for years, pretending to care about the company vision. I've done my time at that.
It helps me that here in the UK the market seems to be upside-down, compared to the US - Contractors are usually more highly skilled and almost always better paid than staff.
That all said, that two month estimate had better be a well understood problem domain, with well defined requirements and a realistic amount of work, because most contracts that small are not, and you'll end up two months down the line with the client wanting to extend a month at a time and all sorts of pressure.
> jQuery simply doesn’t have the complexity or potential power of a full JS MVC
jQuery versus MVC? What is this guy blabbing about. jQuery is a little DSL for accessing the DOM using paths and patterns, instead of verbose chains of accessors. If you just want to access some element nested in the DOM, there nothing wrong with using jQuery; and how does some MVC framework help?
I think it means that jQuery, being just a little tool, doesn't need to be mentioned as some important technology you'll work with. On the other hand if you're required to work with a full-blown MV* framework, this might be different.
It definitely implies that there's something fishy going on though nowadays. In almost any JS runtime jQuery isn't necessary anymore because most of the good ideas are already added to the language.
Whoa! That takes us back to the Dark Ages of 2009. Did they even have Wi-Fi? Man, there isn't going to be any Angular, React or Ember in the code, let alone all three like I was hoping for.
Kindly chill with the snark, and the implicit assumption that I'm some sort of framework lackey. That was the year the iPhone 3g came out. Lots HAS changed since then, not least that Javascript through 2009 was ES3, unchanged since 1999 at that point, 2 years after the language was released.
I agree with buzzwords, but what's wrong with t-shirts, perks and needing specific skills? Personally, I don't think I'd want to work in a place that has a formal dress code, and I'd strongly prefer to work somewhere that has a relaxed environment (e.g. music/exercise room, common area with amenities, etc.)
I think the point is that if you're advertising it, you're trying to either hide something or you only want to hire people who put those things higher on the list than everything else. Some people want to work in an atmosphere where playing foosball all day is cool. Some of us feel that shouldn't be a primary draw.
Yeah I mostly tend to agree... but I'm just being the devil's advocate. I mean, how do you communicate that you're different from a bank? If you genuinely are a cool company, how do you communicate that in a job ad (or other communication)? Probably doesn't need to be mentioned as a "perk" on the top of the list, but should likely be included somewhere towards the bottom of the advert...
Or anything mentioning alcohol. I don't have an issue with alcohol in general, I'll drink socially. But as an indicator of culture it's just the biggest cliche and eye roll for me.
Yep. When the atmosphere is being pushed hard as an asset, that tells me they're padding to make up for other deficiencies. Like everyone's first resume.
Not OP but I work at a major bank and we have casual dress/ping pong/a game room. It's a pretty popular trend right now for major banks to build/buy offices specifically for tech and separating it from the suit and tie culture of the HQs
There's little more annoying than having a foosball table next to your desk while you have a job to do and are trying to concentrate. At one of my previous jobs, there was a foosball table that travelled between rooms - each 8-people open-plan room wanted really hard to be the ones to have it, but usually after a month or two of serving as company breakroom, they wanted really bad to get rid of it. The table kept making rounds between rooms until they finally freed a separate room to put it in.
Games are fine, but many people don’t consider them a perk. Let them be a surprise, no need to advertise them. (Mentioning games is a turn off for me.)
I feel this could go well beyond a blog post. There could be a regularly updated list somewhere on the Internet. My favourite is 'flexible on lifestyle", meaning your lifestyle better be flexible, not theirs :) Or allowing work from home, but better be 'dedicated', aka. being responsive 24/7 and never leaving 'work'.
I agree, there's more to ta job than the technologies used. I'm biased, though, and been around awhile working in most tech stacks.
Just some of the things I prioritize:
1) Engaged, smart teammates
2) Solving an interesting business problem. What's the reasoning behind the softer, I'd much rather work with some legacy technology if it means working with a company with a great mission, vs doing the latest trends for yet another ad-tech company.
3) convenient commute
4) Lifestyle (occasional work at home)
5) Corporate Culture Fit
6) Amount of unplanned work and changing directions all the time
7) Amount of Cognitive load of multiple projects at once
8) Location in town (not necessarily for commuting, but just having a nice place to walk to for coffee, out of office thinking time, etc.)
9) Co-workers passionate about their craft
Re 9: I don't care (directly) about whether my co-workers are passionate about their craft. I care because those who are passionate about their craft tend to produce a lot fewer messes and bugs - which I then have to deal with.
So it's a good sign of other things, but it's not actually the thing I care about.
I occasionally see ads for jobs that request absurd things like having x years of experience in a technology where x is greater than the number of years the technology has been around, but I strongly suspect that these type of ads are not serious about hiring an outside candidate and are just put up for legal/compliance reasons.
Reporting in from Germany where the software situation is still pretty bad in many companies. Red flags are "UML", "Enterprise Architect" (actual name of a software package), and "model-driven development". I can handle legacy code just fine - you have to when doing C++.
> “Early Stage Emmployee / Technical Co-founder / Person to Make My Thing”
A typo in the word “Employee” is another red flag. Attention to quality extends to all things around the office including proof reading job descriptions.
A true red flag I ignored when I was a very young developer was
> 'Write code that does not need to be tested.'.
being a requirement for a junior position.
I came from a freelance background where tests were not a requirement or even unwelcome due to the work overhead and cost.
Suffice to say I did not stay at this company for long.
Some job descriptions include meaningless benefits. For example, in my country, the law enforces employers to contribute to pension. Some job descriptions include "Pension contribution" in benefit section. What????
I'd guess that means that there is a market of unofficial jobs in your country and the description says that they either contribute to your pension at full scale or at some degree by reporting your salary for tax services lower than it is.
In my country half the companies do either of these cause all the taxes on the behalf of the workers and pension contributions are done by them, not the workers.
Ask if this is a new position or refilling and existing position. With some discovery, you'll find if the churn rate on the job offered is high. If so, run. Something is very wrong.
One of my clients is a relatively major educational institution and they still use ColdFusion to drive some in-house CMS abomination. If it ain't broke?
I do still use Dreamweaver templates sometimes though! The awesome static site generator of the 90s. You can give the templates to marketing folks and they can use the GUI to make content updates.
(I know I should feel bad for not using some JS framework that nerfs their SEO and breaks the back button.)
12 years experience in Vue or Backbone? Coldfusion was forgotten in a Flash, sorry for the pun. I do like jQuery, paired with it Coldfusion in the article, because of it's simplicity over what seems heavy React, Angular, and expect it to outlive them. I also expect human readable CSS to return, and for PHP to live a long life.
As a former CF dev I laughed out loud when I saw that part - CF+JQuery. But yeah, it's amazingly resilient. The Java bytecode was quite fast and stable.
However there are certainly better tech stacks available. For one, the variable scoping was nightmare-inducing stuff.
There was actually a post a few weeks ago about a project which is essentially a modern CF runtime, while I still can't imagine anyone using it to build new projects, I'm sure many orgs are still actively using it to glue their legacy systems to newer ones
To me, this is the worst out of all the habits listed here, because it's clearly factually wrong.
Either they're so clueless they can't do math, or they're actively trying to hire liars and only liars.
I don't want to apply for a job that forces me to ignore the truth before I even get in the door. What else are they going to expect me to look the other way about?
You all are overthinking it. To me it's just a sign of a larger company where there's an HR recruiting/hiring department that fronts the hiring manager.
I don't think this is an example of keyword stuffing. I hire a lot on complimentary skills. I bet there's a lot of Ruby Devs out there who'd like to learn and work on an Elixir project.
I've even interviewed at some shops that were Rails-based, but since I had a lot of good OO programming experience, designed and built large-scale systems, had skills with other parts of their stack, I had a better overall skill set than some of their existing Ruby devs. And they accounted for this with part of their onboarding process to get me up to speed in their Ruby codebase....
To be even more explicit, I can't actually see any benefit of trying to keep the technologies the same on both sides of a TCP/IP border. Use the tool that's best for the job, whatever it is.
I think a lot of the worry comes from developers that are relatively inexperienced. We put "senior" tags on positions filled with people with only a few years of experience. Sometimes I think it's hard for newer developers to imagine what it's going to be like 10 or 20 years down the line. Being good at 2 language (or frameworks or whatever) is almost laughable. If you don't have half a dozen hanging from your belt once you've got a quarter or a third the way through your career, I think it's a big problem that you should aim to fix. Picking up something new and being effective and efficient with it very quickly is an incredibly important skill -- one which no programmer that wants to work in the field long term should avoid.
Now, if you happen to have a very young team that realistically can't handle the challenge, then that's a completely different story. It's also very important to understand what your team is capable of.
I agree with all your posts in this thread so far and thanks for giving me a sanity check. I was starting to question my range of interests versus what others were claiming are standard.
I find knowing both backend and frontend to be hugely important in the design of both systems independently.
I've been involved in tech for 2 decades now. I currently follow frontend / backend JS, Docker/Kubernetes, native mobile as well as RN and Flutter, and general DevOps. In the past I've done Office add-ons in C#, game bots in Java, PHP pre 3.0, Visual Basic GUI wayyy back in the day, done API's in Python/Ruby, and used languages I don't even remember anymore due to preexisting codebases or the team choosing something that fits better.
At the moment I think that's unlikely because as far as I know web assembly can't access the DOM. Once that's fixed, C++ and Rust and a few other platforms will be a lot more viable. I'm not sure how popular it will get, though. For example, GWT gives you a pretty complete Java implementation that compiles to JS (I even use it on a project!). Even as popular as Java is, GWT is not so popular. My experience with GWT has been that it's pretty awkward to use. I can't think of a single thing that's easier to do than in native JS. Personally, I think Typescript is probably a better fit for frontend work for people who want types. Disclaimer: I'm an old school C++ programmer that actually likes writing JS ;-) Where I see web assembly being more compelling is where you want to write native apps and port them to a web or mobile platform. JS applications on the desktop require a pretty massive runtime system and if that's your main goal, JS is not really a great option (IMHO).
I'm right with you in terms of being an old school c++ programmer. I'm really fond of the QT framework and they have been doing a lot of work to port their widgets for WebAsm use. This made taking our existing Desktop GUI application and embedding it straight into a webpage super easy. Our backend servers are C++ based and speak JSON via WebSockets so reusing the same objects on the front and backend was also convenient.
Also, I would imaging web assembly could open the doors for much more advanced game engines since a lot of them are written in C++.
Both backend and frontend code has an ecosystem that goes with it and the job descriptions are for the entire thing. Some js framework, css. Linux and databases.
A decade ago it was possible to be a true full-stack developer that kept up with both ecosystems. Much, much more difficult to do nowadays. Hence the explosion of “frontend engineer” positions.
I've been around a long time. I don't think it's any more difficult than it used to be. On the contrary, I think it's considerably easier -- everything comes with source code and all these new fangled frameworks are practically the same anyway.
Back in the day we had client server architectures and it was exactly the same thing. Even more tiers would sometimes be added and there were frameworks for all of them. We didn't get source code. The frameworks were full of bugs. There was no stack overflow. Documentation usually consisted of a few trivial examples. You just had to hack, hack, hack and figure out how it worked. I remember when Swing came out and being very excited about being able to work on something that wasn't completely insane for client stuff (that's how bad it was ;-) ).
This is just the life of the computer programmer. If you like learning new things, it's never a dull moment!
It's not any more difficult than it once was. You don't need to write a mico-servicized containerated whatever system right out the gate just because that's the way some people like to do it at scale. There are tons of people out there making bank off of sites that are just highly customized wordpress instances, after all. You've got to use the tool appropriate to the job. Certainly today the high end of what's built on a regular basis in terms of web apps is a lot higher than it used to be, but if you have a need to support that level of traffic you either have the ability to hire a team of devs or your business / monetization plan is dysfunctional.
If you really believe that I think my story will blow your mind.
I've been a full stack developer since my very first job creating a Java based web app for a startup where the only other coder was the CIO. The CIO didn't know Java and primarily worked on C/C++ embedded code for unrelated projects. Back at this time raw Java servlets were still "the thing" and javascript with jQuery was state of the art on the front end. With just these primitive tools I built a fairly modern even by today's standards reactive web app. Lots of stuff loaded dynamically based on user interaction without switching pages. It was a legit web app, not just a web page. Actually, I was more than a full stack developer. I was also the sysadmin, dba, and network engineer. I physically installed the hardware at the AT&T data center, created a DMZ with the firewalls, configured load balancers, installed the DB and set up a hot backup, literally everything that needs to get done to make a working web application. There was no one around to learn from, it was all web searches: how to secure Apache, how to set up certificates, how to create indexes on the database... everything.
I ultimately decided I prefer back-end development so that's where I spend most of my time these days. However, in recent years I've picked up Angular and Backbone because sometimes the front end team needs some extra bandwidth and being able to help out is really valuable. I'm not as good at that stuff as the dedicated front end guys. I certainly didn't do as good of a job setting up the network or eeking out max performance on the database at my first job as dedicated professionals would have. But I got the job done at a professional quality level. My first job was surely a rather unique experience, but everywhere I've worked multiple people on the team have been comfortable all the way up and down the coding stack, even if they might have specialized in just one area.
This actually sounds pretty ideal for someone early in their career. Having to do that much must have been a great learning experience -- one of the perks at working at a startup.
Definitely. In spite of the insane hours I worked sometimes to keep that ship a float, it was a really amazing and unique experience. I feel really lucky to have started out there. I left the company about 13 years ago and the product is still running and profitable. I did one rewrite from raw servlets to Struts while I was there. They've tried two rewrites since I left to get it into more modern tech, but both rewrites failed, so a LOT of my code lives on. That's a really great feeling knowing that something I created is still valuable and useful over a decade later.
That depends on a lot of factors. "Fullstack developer" can often mean "we just want a donkey to ride for whatever purposes we need", often overworked and underpaid. But not always. Plenty of people have very broad skillsets and can work on projects that go from systems software dev. to front end web design to sysadmin duties to customer service. In really small companies often there just isn't a possibility to hire people to fill out all the jobs that need to be done as different roles. What one should evaluate is what the tradeoffs are. Do you have a lot of autonomy and authority married to all of that responsibility? Is there some acknowledgement that you'll need downtime (e.g. vacations)? Are there non-monetary compensations built-in like flexible work hours, ability to work remotely a lot, ability to prioritize one's own work and make decisions on scheduling? And, of course, equity. In other words: are you treated as a peer, a co-founder, or an underling?
I think it's 'fine' for there to be different technologies/language on different sides.
Typescript/JavaScript front end.
Python, Java, .net on the back end.
Database written in C++
OS written in C.
There are certainly jack of all trades developers that can do that for you. You will get a jack of all trades solutions that may have oddities here and there. Which could be okay depending.
I mean, there are a lot of languages that can be used both on the server and in a browser. JavaScript is the obvious one, but anything that compiles to js works, too.
Until probably the last 5 or so years this was the norm. Until Node.js became widely used as a web developer you were essentially required to know JavaScript and at least one of Python, Ruby or PHP. For companies trying to shift away from these legacy environments or those who haven't started yet it's pretty reasonable for them to try and hire those kinds of devs still
Since people realised writing the same code in two different languages is a waste of time and the async-first nature of NodeJS/libuv is ideal for use in microservices.
Compare implementing back-end form validation in PHP and a completely different implementation front-end validation in JS vs using the exact same implementation on both sides. The former approach requires more work, creates a larger maintenance burden and a greater area for inconsistency and error because you need to maintain functional consistency between the two different implementations in the two different languages
Two Month Contract
That's music to my ears. It signals two important things: First, it's a real contract and thus going to pay really well. Fake contracts present themselves as "contract to hire" or similar so that that they can convince you to agree to a rate of "half your salary, but paid hourly without benefits". But for two months? You're going to hear about my five figure per week rate.
And it's short. Two months and I'm out of there short. So no matter how toxic the environment and how terrible the codebase is, it makes no difference. A guy can stand anything for a couple months. Especially in combination with that first point, which means that this is possibly the only gig I'll need to take all year.
Cold Fusion
Oh yeah, bring it on. This translates as "You are possibly the only person on the planet who knows how to do this work. Charge us accordingly." If you find this in combination with one of the short gigs from above, your life is about to get really good. Your only real problem will be keeping a straight face when you quote the rate you're going to charge for this contract.
In the end, I think it comes down to what you're looking to get out of the job in question. If, like the author seems to be, you're looking for a long term career at a new company then no, you're right, run away from these places.
But if you fancy a bit of fun quick contracting, this article is mostly a list of bill rate multipliers.