________________________________________________________________________________
I was in a job I absolutely hated up until not that long ago. Initially I was very happy with it - as a developer, I loved the fact that there were no calls lasting hours filled with made-up acronyms and the usual "we should", "we must" and all that. But to be honest there were other red flags from the very beginning which I completely ignored(and I shouldn't have). The tech stack was horrible: infrastructure was 2010-ish at best, the deployments were absolute rat shit(45 minutes to deploy a new version on single digit number of servers, just deploy, which included no tests and no builds), the code was equally horrible - linters were a no-go(the so-called head of engineering had his own understanding of how code should be formatted), open a random file and you will see every anti-pattern known to man. Dependency tree was 500 lines long. Every common problem had a custom solution instead of the freely available industry standard ones. And speaking of the code, it felt like seeing the large perl codebases with 30k+ line files from the mid 2000's: mixing paradigms in a way which only makes sense to the person who came up with them and no one else. Needless to say that a few months into it I hated every single bit of it. Worst of all is that for one reason or another, the developers were not only fine with all this, they had picked up every single last bad habit - mixing functional and object oriented programming, the wretched formatting, everything invented past 2010-11 was considered witchcraft and so on. I admit, I tend to swear when I don't like something I work with. But here I was swearing all day, every day from the depths of my throat. I can't describe how awesome it felt to do a $find -iname {company_name} | xargs rm -rf after my last day.
Two very important lessons:
1. Never EVER ignore red flags. Ask about tech stack, procedures, code-reviews, opinions on basic programming principles and everything you can think of. Generally the interviewers should be asking these questions but it's equally important to see how they see the world. A simple thing to keep in mind is that if someone thinks they know better than the veterans in the industry with dozens of textbooks on the subject, chances are they are morons. If you see something odd, ask more questions. For instance why use mercurial over git: If you get an answer such as "well we evaluated the two options and there really wasn't any benefit to git and only made things more complicated" - run for your life. In the case described here, it turned out that the head of engineering didn't know how to use git and was confused by it.
2. Ask as many questions about the tech stack as possible - there are 3 possible options: One is the company uses what it uses because it was inherited from someone else and they stuck with it. Two, they picked some technology because they wanted to use it and not because they had to. Three is they picked what seemed the most appropriate but are willing to explore alternatives. Ideally you should be looking for the third option.
Could you DM me where you worked? It sounds like a great place to work personally!
To be fair, git and mercurial are very similar. I wouldn’t recommend anyone to go with mercurial for a new project because of the network effects of git but I’ve used and been happy with both.
Many years ago I used svn at an old job. To be honest if I had to choose between mercurial and svn and death wasn't as option, I'd choose svn. Mercurial feels like the product of unsolicited help(which turned out to be the case when I read how it came about). And if you look at how it works underneath, it's practically the equivalent of trying to mass print books using Gutenberg's press in the 21st century.
Such code exists basically in any company what has been around for more that 20 years. Working with a legacy code is a challenge, yet do-able.
Thing is this wasn't a 20+ year old company but a relatively young startup. Average age in the dev team must have been around 27-8. At 33 there were only 3-4 people in the entire company that were older than me. Should have pointed out: this wasn't perl, only perl-like approach to everything.
Sounds a lot like a place I once totally noped out of.
Seemed good at first because it was fairly hands off. Turned out I got tricked because the part of their ecosystem I initially got a glimpse of really was just a small thing that wasn't really representative of anything else they were doing.
Most of the tech stack was pretty old and horribly maintained. Frameworks remained severely outdated and obvious antipatterns were used to keep them playing nicely with some things that were at least a bit more up to date. The codebase(s) was way too big and unwieldy for what the product was actually doing. Strings and configuration that were liable to frequent change that should have been served from an API were all hard-coded and required multiple things to be deployed simultaneously for even the smallest modification. The code was just dreadful, and there was an anti-documentation culture in the team. Lots of the other engineers were clueless, and I couldn't blame them because I was clueless as well. The smallest changes took forever to implement without causing significant breakages. The QA team did no automation and failed to catch a lot of things. Code review was an absolute joke. There were _tons_ of dependencies, including ones that were totally nonsensical. The only real sort of coding style or preferred design pattern, if you could call it that, was to use OOP up the wazoo, with several layers of needless inheritance. It was hard to make sense of anything and I was forced to jump through tons of files to figure out how something worked. There were lots of things in the app that no one could explain, and nobody seemed to think any of these things were problems. I'm sure I could have remained there indefinitely, but in my opinion it's damaging to one's sanity to go through the motions and pretend like that's all fine. So I walked.
> A simple thing to keep in mind is that if someone thinks they know better than the veterans in the industry with dozens of textbooks on the subject, chances are they are morons.
That depends on what you are looking for, though. They're probably morons if they are looking to hire a junior developer. If they're hiring someone more senior, I don't think it's obvious that they might be morons.
Honestly, I find what a lot of veterans evangelize about to be bullshit intended to sell books. If I'm interviewing somewhere and I find out that they hate the overuse of OOP as much as I do, going against what a lot of veterans said for years, I'm more likely to be intrigued.
The heart of your first point is totally valid. If something doesn't smell right to you, just move on. You don't even need a reason. Almost every time my spidey senses tingled, they turned out to be right.
> Ask as many questions about the tech stack as possible
I wish I could _see_ the code before I sign an offer. If I could see the code, that can tell me almost everything I need to know most of the time.
> I wish I could see the code before I sign an offer. If I could see the code, that can tell me almost everything I need to know most of the time.
This is why contract-to-hire, for all its downsides shows a strength. Being a contractor, you get the experience of the company without becoming enmired in all its bullshit.
To try to extract this information in the 10-15 minute “what questions do you have for me?” phase of most interviews is nearly impossible.
≥ That depends on what you are looking for, though. They're probably morons if they are looking to hire a junior developer. If they're hiring someone more senior, I don't think it's obvious that they might be morons.
I think you misunderstood me. I'm talking about the sheer basics from people like Kernighan or Robert Cecil Martin. If someone at a small and largely irrelevant startup had the pretention to know better than them, them they are the definition of morons.
"You alone get to decide how to perceive an opportunity, and you’ll serve yourself best when you cease looking at settling as an action that subtracts something"
This is how I looked at jail. It gave me time to fix my diet and exercise. It gave me time to read. I read over 800 books while I was locked up. I guess there is a positive side to a lot of things that appear totally negative.
Note: _everything_ is non-ideal.
I think non-ideal is an euphemism. Being negative in American media doesn’t look good.
Unless it's your whole business model, in the case of some elements
1. found out that the current position is not worth it
2. keep working as usual (don't overwork) and spend rest of the time interviewing
3. ???
4. profit