5 ms·

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 t

by Oras 6y ago

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.

nkingsy 6y ago
Popular open source tools are a poor substitute for standards, but they are better than nothing. Standards matter if you want to show your code to someone else
paledot 6y ago
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.
- ric2b 6y ago
  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.
  - solipsism 6y ago
    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.
    - scottLobster 6y ago
      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.
      - solipsism 6y ago
        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.
- scottLobster 6y ago
  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?"
  - paledot 6y ago
    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?"
    - scottLobster 6y ago
      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.
moksly 6y ago
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.
- Oras 6y ago
  > 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.
  - 01000101 6y ago
    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.
bstar77 6y ago
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.
- solipsism 6y ago
  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.
  - bstar77 6y ago
    > 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.
    - solipsism 6y ago
allenu 6y ago
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.

by Oras 6y ago

nkingsy 6y ago

Popular open source tools are a poor substitute for standards, but they are better than nothing. Standards matter if you want to show your code to someone else

paledot 6y ago

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.

ric2b 6y ago
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.
- solipsism 6y ago
  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.
  - scottLobster 6y ago
    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.
    - solipsism 6y ago
      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.
scottLobster 6y ago
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?"
- paledot 6y ago
  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?"
  - scottLobster 6y ago
    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.

moksly 6y ago

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.

Oras 6y ago
> 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.
- 01000101 6y ago
  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.

bstar77 6y ago

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.

solipsism 6y ago
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.
- bstar77 6y ago
  > 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.
  - solipsism 6y ago

allenu 6y ago

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.