This is exactly why the more I think about it, the more I just want to git-push-heroku-goodbye and be done with it.
I don't care about setting and maintaining AWS instances, docker containers and jenkins.
The older I get, the more I realize how precious my time is and now I have very little patience for anyone or anything that wastes it.
This is also why I've basically cut off all social medias from my life (except HN occasionally), have always preferred working from home to avoid wasting time in traffic, have cut off people who I don't enjoy spending time with and spend more time with my family instead.
Sadly the extended out of state family seems to like FB, and I try to follow science/math twitter.
As you get older, something in you clicks, that you realize that time spent being angry, or combative, reduces the time you have for enjoying things (family, life, etc.).
Your time on earth is a zero sum game. Maximize its utility, maximize your enjoyment, minimize your negativity (e.g. outrage of the day on social media). Your life will be better.
Even better (imo) is going beyond the maximization maxim and realise the “beauty” of the analog, a world you directly see, hear, touch. Just existing without a specific goal, which is indeed similar as a vacation / holiday. However people seem to reserve the “no goal” mindset only on vacation, but you could also integrate it into your life.
Hear hear! I wish one day the dev community will understand that its never about the tools and more about the delivery. The customer does not give a monkey if the backend is node, go or PHP. You do not impress anyone by using React, redux, amber, angular ... etc. All people care about is a solution to a problem they have.
However, from my experience, this is not a popular opinion among developers.
It's not popular because it's not realistic in most environments. In many cases it's advantageous to use those things you listed because that's what the market can provide talent-wise. I'd rather deal with learning new tech that's well documented than some custom lib that "just works" but no one understands because the architect left years ago. My whole career has been about consistent education, so that doesn't intimidate me. Working on undocumented architectures that I have to make substantial changes to (and not knowing all of the side effects) is what intimidates me.
Turnover is a reality that can't be ignored. New people come in and now have to figure out something that reads like a stream of conscience. It isn't well documented, doesn't follow the latest best practices and doesn't support modern paradigms and uses outdated frameworks/libs, but works great.
The apps I build always take into consideration the talent pool my employer intends to pull from. The reality is that they (usually) can't hire general "technologists" that are proficient at all layers of the stack. If the project is something that only you will ever work on, then you can do whatever you want and this whole conversation is moot.
it's advantageous to use those things you listed because that's what the market can provide talent-wise
More silliness. Pay developers enough so that they'll stick around. If they stick around, then you don't need to hire for talent in a particular framework or language. You can hire for intelligence, creativity, passion, drive, whatever... and invest in training people when they get there.
Jumping from framework to framework and language to language as the talent pool does is incredibly wasteful.
> Pay developers enough so that they'll stick around
It's amazing FANG companies have any turnover based on that logic. Turnover happens for a variety of reasons... like global pandemics... you can't make a blanket statement like that and expect to be taken seriously.
I believe you have agreed with me in your points especially regarding talent and turnover. The shiny tech today will be a legacy 6 months later or a year if you’re lucky. Then the talent pool will change and you can’t attract the devs who religiously follow new trends. You’ll end up hiring people to deal with your {legacy} system or as you pointed out .. substantial changing it.
React/Redux/Angular all have staying power so I don't understand your point. I don't know what you mean by "shiny" tech. Other than specific libs that go unmaintained, most popular tech has some staying power.
That’s not a universal truth. Java was shiny once upon a time. Rails was shiny once, even C was shiny once. This stuff is still being used (not legacy). I’m sure when rails first showed up, people were calling it a fad.
In JS land there’s a ton of churn though for sure if that’s what you were thinking about. Not all of it though.
Being used does not mean it is not legacy. Do you consider a system running in Java 6 up to date? But if it is stable, serving customers requirements then there is no need to replace it.
The point I am making is, using the current {shiny} tools might not be the correct answer (it could be though depending on the use case). Just use whatever gets the job done faster and then iterate. Some developers will start solutionising based on technology instead of focusing what is the purpose of the system and how it will help users. AKA: CV driven development :)
Which is why I open my conversational interviews with, "There's an emergency, sales promised a customer a to-do list app yesterday. It's getting shipped out and forgotten, you're doing it on your own, only thing that matters is it's done fast. What do you use?". And then of course I spring the, "Okay, now it's becoming a flagship product. How do you onboard co-workers? How do you pivot to ongoing maintenance? What problems do you anticipate scaling it out?". But it's always important to have a tool in your toolbox to hack something together in an afternoon, even if it's just to prove a point.
As a candidate that would be a hell of a red flag, particularly as an opener. After answering I would definitely follow up with "are situations like those an expected part of my day-to-day?" and minutely examine your response. Even if the rest of the interview went swimmingly that opener would give me pause after the fact.
That question translates to me as "your sister teams/leadership/communication infrastructure are completely incompetent/lacking and you're on the spot to pull an 18 hour shift to clean up their mess. What do you do?"
Sure occasional unforeseen emergencies/breakdowns in communication are expected even at the best of companies, but I'd replace it with a hypothetical that makes the company sound fundamentally competent. Perhaps something like "The company has promised the customer a To-Do List App, however automated testing failed to catch a mission-critical edge-case. This comes to light the day before it's supposed to be delivered. The flaw is so fundamental that the app will have to be re-written. Everyone else is handling other parts of the delivery, so you're on the spot to do it on your own. The only thing that matters is that it's done fast. What do you use?"
I'd make a note of that response and count it in your favour. But if you get sidetracked enough that you never end up answering the question, that's also not a good sign.
IMO your counterexample is wildly implausible, and is likely to sidetrack the candidate. "Is nothing salvageable? What was the flaw? What automated testing? Do I have to use that testing in my alternative fix? How does that reflect on the rest of my tech stack choice?"
True, just came up with it off the top of my head. I suppose it is possible to be too detailed in such questions. Point being it at least makes it sound like the company was doing the right things and got hit out of left field, vs stepping in a pile of their own making and making you responsible for fixing it.
Perhaps a more innocent miscommunication like the customer failed to clearly communicate requirements, and it was just discovered in an email conversation that they were expecting and as-of-yet un-implemented To-Do List App in the current release, which is shipping tomorrow/this week/etc. I've experienced situations like that before, not sure how applicable it is to your business.
Perhaps a better way to phrase it would be along the lines of, "You propose a to-do list app at a team meeting, and you want to demonstrate that it's a feasible product. However, you have a limited time box to ship it in. What do you reach for?" It lacks a bit of the urgency of the original question, but still comes with time constraints.
My original example is born of a decade of cynicism, and you're right that it could reflect poorly on the company. Thank you for the feedback, though in fact I'm happily unemployed right now.
Fair point. I'd say it's sensible for the candidate to assume that context added to any hypothetical is there to inform their answer. Why add the context if it's not meant to inform? At that point it becomes fluff at best and misleading at worst.
It would make no sense for an interviewer to provide meaningless context unless they were deliberately attempting to distract from the the question, or are otherwise simply incompetent/unfocused. I don't see how gas-lighting candidates would be a productive mode of interview, particularly given that each party only has the interview from which to judge each others' character. Even if the candidate were to successfully discern the gas-lighting, all it would do is prevent trust from being formed. At that point every interaction would be subject to question.
So with the assumption that gas-lighting is not the intent and that the hiring party is competent, the question is how is the context meant to inform the response?
Given that the interviewer is gauging the candidate's ability to perform a job, it is sensible to assume that realistic-sounding context applied to a question is meant to see how the candidate would perform in what the interviewer deems a "realistic" scenario.
If the scenario is unrealistic but meant to impart other information, then it should be obvious or stated as such, so that the candidate can attempt to parse to the correct information from the scenario to inform their response.
If the point is merely to motivate the candidate to answer the question by placing themselves in a narrative, I'd argue they should be motivated enough by the fact that they're in a job interview, without the need for unrealistic scenarios. If they aren't then they clearly aren't taking the position seriously or likely have other issues that would impact their job performance even if hired.
Take the hypothetical removed from context: "You have make a deployable to-do list app as quickly as possible, speed and basic functionality are the only priorities. What tools do you use?..." That format accomplishes the same goal of revealing the candidate's knowledge of what a quick/dirty workflow looks like. The followup questions mentioned "what problems to you anticipate when scaling the solution? How would you on-board coworkers? How would you shift from rapid development to ongoing maintenance? etc" would then flesh out the candidate's knowledge equally as well.
> Even if the candidate were to successfully discern the gas-lighting, all it would do is prevent trust from being formed. At that point every interaction would be subject to question.
That would give me a bad impression as a candidate.
It's like you're aware of the issue (sales doesn't give two shits about the capacity of the engineering team) but you want someone that is good at wasting a lot of time efficiently instead of improving communication with the sales team.
And then as a hiring manager I get the impression that this candidate doesn't understand hypotheticals, which is a big red flag. Happily, we will come to mutual agreement on whether you proceed.
As a candidate I by definition know practically nothing about your company and how it operates internally save for maybe some glassdoor reviews, and you're supposed to be judging how I would perform as a part of said company, same way I'm judging whether the position is worth my time or not.
If all your hypotheticals revolve around cleaning up the mess of flagrantly incompetent coworkers/leadership I'm going to get the impression that that's what I'm expected to do all the time. You could get the same information with different hypotheticals, so there's no point in making your company sound like a horrible place to work.
Happily, we would come to a mutual decision that I should produce profits for someone else. It sounds like you're one of those managers who wants supplicants, not applicants. Good luck with that.
I wouldn't hire someone without telling them plenty about where they will work. You don't have to guess what the workplace is like by decoding my questions. You are certainly welcome to, but the obvious danger is that you will get something wrong. A mature person would just ask, and that's the type of person I would want to hire.
It sounds like you're one of those managers who wants supplicants, not applicants.
Absolutely not. I want human beings with whom I can have a good relationship with, based in communication. I definitely don't want to hire a robot who is making important assumptions based on questionable (and totally wrong) heuristics, and Not bothering to ask simple questions.
So yeah, someone applying a weird algorithm to the questions I'm asking them isn't going to be a good fit.
Isn’t the development community sort of there? I mean, most things are still run on PHP, and honestly, I recently saw an open source “forms for the public sector” thing build in Drupal, and now I’m wondering if we’ll ever need another custom programmed form for our web facing applications.
Yet if I go back to my non-management dev friends and talk about this, they are all like “eeeew, what about X and Y” and I’m just like, but neither the citizens or my IT operations staff gives two shits about any of that.
I’m not going to say what is right technically, because I’m not qualified to do that, but I do know what will happen as it’s my decision, and we’ll be slowly moving all our customs forms to a PHP CMS system and we’re just going to shoot the docket container it comes in directly out into our internal Azure cloud with public access through our national identity system (NemID). My developers aren’t going to be out of work either, but instead of making the same form with small differences 9000 times, they will be building Drupal modules with actual challenges.
> Yet if I go back to my non-management dev friends and talk about this, they are all like "eeeew, what about X and Y" and I'm just like, but neither the citizens or my IT operations staff gives two shits about any of that.
That's exactly what I meant. I remember arguing with a colleague who over-engineered a simple ORM table by having 3 classes. One was just an empty class, the other was an empty interface, and the third was the actual class. When I asked why did you make it this way? He said: "What if we decided to use Mongo later?
Technically he was right but practically, he was wrong! I saw this overthinking and over-engineering pattern across many in-house dev teams. But this is just my experience, and I'm not judging what is right and wrong from devs point of view. Every decision has its context, but I saw how these complications affecting the delivery and customer experience badly.
For some reason the first time I do something I always over engineer it... it took me a lot of self growth to take feedback like yours seriously and not get defensive of my “what-if” thought patterns.
I’ve gotten into the habit of just pumping out a naïve solution without worrying about anything and then throwing it away and re-building more thoughtfully because now I have full sense of the scope and some immediate edge-cases. As long as the thing is small enough to do that.
Yup, I agree it's likely not a popular opinion. In my experience, developers love developing frameworks and tools, even when it isn't necessary.
I mean, it's just fun. Developers are biased to do things that make work interesting, even if it's superfluous. We think that coming up with a better framework or tool will save time in the future. I think that often it's just a wash or a net negative since you now have to maintain this tool AND when you first start on creating it, you are sort of naive about what it needs to support, so you open yourself up to a lot of hurt later when clients of your tool come up with more requirements than you envisioned.
I completely overbuilt a recent side project and ended up scraping the whole thing because it wastes too much time to maintain it. As much as I love building new projects, having children at home reminds me that time is my only true resource and it's better spent with the kiddos (at least at this stage of my life).
Asking because I feel this way a lot too -- is this the kind of thing that was avoidable (IE if you built it on Rails/Django + Heroku would that have cut down the maintenance), or was there intrinsic complexity to the project that made it unavoidable?
More and more, I want to build things that are in the former category if I build them at all outside of work.
In my particular case, I opened the CI/CD can of worms using Docker (which obviously has great use cases). My use case could have fit into a Rails/Django + Heroku model that would have saved me a bunch of time. I thought by investing in the infra early it would save me time later, however later will likely never come. So basically I spent more time debugging issues due to adding infrastructure complexity than developing the actual project.
TLDR; Wasn't a total loss as I did learn some, however I would have rather spend more time on developing the actual product (or in retrospect more time with my family).
This tech is great when someone working full time at your company sets up all the scaffolding and you just code your microservice with magic happening around it. Not so great when devs trying to spice up their resume start implementing these ideas to their own personal projects during their free time. I've spent so many hours fighting Basel, gRCP, API gateways, tracing etc etc, just because it's nice at work. But took too much time to replicate something own my own, and it is of course, fragile.
Depends on what you're building. Rails/django/heroku are web app accelerators. If you are building a web app, then yea they make it super easy and take away a lot of having to think about complex systems, but if you're building anything else not really
Are you sure about that? You get a ton from a batteries included framework, but it doesn't prevent from successfully building a complex system, nor does it preclude you from having to reason through the powerful footguns.
The way I'd describe it is that /most/ codebases can fit into what you'd call a "web app" including most codebases that include complex systems -- there are, of course, significant exceptions.
I still use Heroku for almost all my personal projects. I stopped for a while, but they now allow you to dockerize your projects and push them to their registry. They also allow you to have multiple apps with access to shared resources. Those two changes have made it much more flexible than it was back in the early days.
You never realize how much configuration of AWS is like pulling teeth until you stop.
I'm going through literally what you mentioned last. I had a very simply API built on lambdas for a side project, that worked perfectly fine till last month. But now, every minor change I make to that code results in some error or the other that I can't figure out for the life of me. It has been so bad that I had to quit the project altogether.
Ditto, recently moved from AWS to render.com
It's like a cheaper Heroku, it's been stable so far.
I do use GitHub actions to run a small pipeline on projects but its a far cry from Jenkins.
I recently switched all of my personal projects from being self hosted on a linode with a complex nginx setup to just using Netlify... never going back.
I don't care about setting and maintaining AWS instances, docker containers and jenkins.
The older I get, the more I realize how precious my time is and now I have very little patience for anyone or anything that wastes it.
This is also why I've basically cut off all social medias from my life (except HN occasionally), have always preferred working from home to avoid wasting time in traffic, have cut off people who I don't enjoy spending time with and spend more time with my family instead.