6 ms·

Protein interface – how to change aproach to building software?

49 points by catinblack 4y ago

catinblack 4y ago
I read this article recently. It fell into my hands by accident and I found this quote there: -- Assuming that we should launch many pilot projects, let’s consider for which of them it is possible to build minimally viable products – and then try (where possible) to use low-code and no-code tools. With these, we can get less technical people prototyping quickly (of course, more complex integration pieces may still require the help of an engineer). Thanks to the fast implementation, managers or people responsible for the functioning of the process in the company are able (within a few weeks) to check and analyze the sense of an idea. They can test it in a natural environment, and if everything works, they can create a dedicated solution developed by an experienced team. -- One of my close friends, whom I advise in the field of digitization, owns a factory. I can't convince him for anything to try this approach, which I think is absolutely right. The client believes that only their IT department and CTO can change anything in automation. Or only they can be responsible for data analysis. How to change this, how to convince him?
- csours 4y ago
  IT and the CTO have tried very hard to convince them of this because IT and the CTO have seen the hell-sewer that shadow IT creates. The hell-sewer is real, but banning shadow IT is not the right answer. --- Above is the answer to your question, but it raises the question - what is the right answer to shadow IT? The problem with this question is that it sounds like ONE question, when in reality it is a many segmented question. You need a way to characterize the shadow IT in question so that you know what approach you should take. If shadow IT overlaps with governance, then it should not be shadow IT. If shadow IT does not, then it's probably fine to stay that way or be replaced at some point by a MVP. --- That answers the question I raised, but now I've raised another question: WTF does "overlaps with governance" mean??? And this is where the nightmares begin!
  - catinblack 4y ago
    It's not even that they are supposed to use some solutions without the approval of the IT department. The IT department could, for example, prepare some sandbox for people to play with. They can create separate systems and with their consent and approval people could "play" with ideas. I feel under the skin that there is huge room for innovation.
    - csours 4y ago
      I don't dispute that at all. This could happen. It should happen. IT has an allergic reaction to Shadow IT because they know about the times they had to deal with it. Understanding what IT has had to do in the past to fix things helps you understand why they don't think in these terms.
      - ok_dad 4y ago
        Shadow IT happens when the user isn’t getting what they need. I wrote software in excel at one job that did the priority planning for incoming inspection, because we didn’t have anything we could use to do that other than SAP and I wasn’t going to engage with that system due to effort required.
  - clcaev 4y ago
    Shadow IT could be seen as ignoring externalities such as security, operational resilience, and process coherence in order to "get things done". Eventually the bill comes due (security incident, key employee exit, incorrect results). Questions are: can you recognize failure? who pays to fix it? what happens while it's being fixed?
- openfuture 4y ago
  I think what you are describing is basically a good development environment.. where you can contribute your insight at depth of skill level appropriate for what you have to offer. From my point of view the path to the eventually persuasive version of this enviornment (i.e. where your friend and the CTO will accept to use it at their factory) starts by setting a common standard for data interchange between the tools. So partial work can be commented on and different options for completing it can be assessed relative to one another. I'm just one person but I am on my way and datalisp.is my starting point ... I am certain that the road goes by your place on the way to prosperity.
  - catinblack 4y ago
    Thanks for this vote. Good point with the standardization. I take it.
maxbond 4y ago
Have people worked in such a place where "on deck" engineers are hired out? Why wasn't there enough work to assign? How long were you contracted out for? I'm having a hard time imagining how this would work. It seems to me like it won't be very long until there's work people will need your help with, and that by the time you've gotten up to speed on things with this other company, you'll be parting ways. I have to imagine there are some interesting relationships and circumstances that align for such things to happen.
- brundolf 4y ago
  It's bizarre and the article is vague about it, but if I had to speculate: Tech-first companies always have more software work that can be done; if not, they come up with new work to expand the business (features, scaling, etc) But maybe this could happen at companies where software just supports the primary business? If the software isn't the product, and it's currently doing everything it needs to do for the business, I could imagine a scenario where IT people might become idle
  - ChrisMarshallNY 4y ago
    I've never encountered anything like that, myself, but I have been in sort of a "silo," for most of my career. The author may be in a contract outsourcing shop.
    - brundolf 4y ago
      Yeah. This situation is entirely alien to my career, though I've also never worked at a non-tech company (hence the speculation)
  - PeterisP 4y ago
    The market is quite different in different countries. It seems that where the OP is located (Poland?) the job market is dominated by "IT companies" as in large contracting shops, not "IT companies" as tech product companies employing huge numbers of in-house developers.
scotty79 4y ago
I have nothing against being called a resource and treated as such. It's a clear deal for me. I do my stuff and bear as much responsibility for your business and care for it as much as lump of iron. Any other arrangement seems to me like different flavor of "we are a family" dishonest.
trhr 4y ago
I've been writing code for 30 years, invented three algorithms, have managed engineering teams and been trusted with half-million-dollar tech budgets, but because I don't have a C.S. degree, I rarely get into a final round. Maybe changing the expectation that good developers must excel at LeetCode is a place to start fixing the shortage that causes this problem in the first place. I excel at perceiving contexts and understanding when to change approaches, but since you can't test that in a tech screen, it's basically a worthless skill to have.
- vecter 4y ago
  You sound like you have a really valuable experience and skillset. In your opinion, how would you go about technical interviewing in a way that makes sense?
  - le-mark 4y ago
    Have a conversation with someone who can recognize the experience, and not be threatened by it. Look for the candidate to tell war stories about technical challenges, leadership challenges, interpersonal challenges and how they solved them and what they learned. Read their resume and recognize multiple stints of increasing responsibility at quality companies means something.
  - ChrisMarshallNY 4y ago
    I can: A) Relate to the GP, and B) Answer the question For (B), my experience was that LeetCode was worthless, as I was looking for a senior-level engineer, to come into an established team, and start being a contributor, ASAP. I spent 25 years, hiring experienced coders, and ran an established team, that was part of a much larger, established organization. Headcount was really difficult for me to get, and the company was cheap. They were a huge name, and assumed that everyone was fighting to join the company. If you were a photographer, that was the case. If you were a programmer, that was definitely not the case. So I had a challenge. I suspect that the low-end salary chased away most people that were only looking to hop onto a short-term, salary multiplier gig. Pretty much everyone that I interviewed was serious about getting involved in some extremely interesting work (C++ image processing pipeline development). I got folks to talk about their passions and projects. The best way to figure out how folks work, is to ask them to wax eloquent on problems they've solved, and projects they wrote. I would have killed for large GitHub portfolios. I loved long résumés, and would definitely have spent a lot of time, reviewing them, if they were offered. I think I basically made good choices. There was never a technical misfit. In a couple of cases, the person couldn't integrate too well into the team. I had a very relaxed environment, and each team member had their own proclivities and workflow. We made it work; I suspect the fact that they all had decades of experience, helped. I kept people on board for decades (not an exaggeration). Remember I said that headcount was such a bitch to get? That was a big reason for me wanting to keep people. Also, the Japanese team would barely acknowledge their existence, until they had been at the company for at least a year. In my experience, someone who is good at interview tech questions, is good at interview tech questions, but that does not give me any clue, as to how they will be, when they hit some of the rather hairy (often threaded) algorithms we had. I had to take risks. If an employee did not work out for at least a couple of years, I got grief. So I got highly competent, experienced C++ engineers to join, for low-ish salaries, and I kept them, for many years. I guess that's not a valuable skill, in managers, anymore. I think I did OK. [UPDATE] I made it more about me, to try to make the comment a bit less abrasive.
vsareto 4y ago
>Good software engineers are characterized by determination and persistence, thanks to which they can deliver effective and intuitive solutions to end users. They must have a rich imagination, be up to date with industry trends, read a lot, stretch their knowledge to the limit, challenge the status quo, and go beyond their comfort zone every day. Now do the other roles around software and you'll quickly realize this is heavy idealism. And sometimes those roles are even paid more.
- pipeline_peak 4y ago
  The only thing I ever had to be "up to date on" was my deadline, the valued knowledge was always product specific. Idk why all this "shake things up" brogrammer Mr. Robot persona keeps buzzing by my ears, but never in my past 4 jobs have I heard "on the bench". I haven't worked at the most exciting places, but for every Google there are 10,000 DoD, Health Insurance, Asset tracking legacy-ware firms. They're workin hard, but I wouldn't quite say "challenging the status quo" lol.
TruthWillHurt 4y ago
Total fiction. In over two decades I've never seen engineers on the bench or hired out. maybe in scummy agencies, but not in proper companies.

49 points by catinblack 4y ago

I read this article recently. It fell into my hands by accident and I found this quote there: -- Assuming that we should launch many pilot projects, let’s consider for which of them it is possible to build minimally viable products – and then try (where possible) to use low-code and no-code tools. With these, we can get less technical people prototyping quickly (of course, more complex integration pieces may still require the help of an engineer). Thanks to the fast implementation, managers or people responsible for the functioning of the process in the company are able (within a few weeks) to check and analyze the sense of an idea. They can test it in a natural environment, and if everything works, they can create a dedicated solution developed by an experienced team. -- One of my close friends, whom I advise in the field of digitization, owns a factory. I can't convince him for anything to try this approach, which I think is absolutely right. The client believes that only their IT department and CTO can change anything in automation. Or only they can be responsible for data analysis. How to change this, how to convince him?

csours 4y ago
IT and the CTO have tried very hard to convince them of this because IT and the CTO have seen the hell-sewer that shadow IT creates. The hell-sewer is real, but banning shadow IT is not the right answer. --- Above is the answer to your question, but it raises the question - what is the right answer to shadow IT? The problem with this question is that it sounds like ONE question, when in reality it is a many segmented question. You need a way to characterize the shadow IT in question so that you know what approach you should take. If shadow IT overlaps with governance, then it should not be shadow IT. If shadow IT does not, then it's probably fine to stay that way or be replaced at some point by a MVP. --- That answers the question I raised, but now I've raised another question: WTF does "overlaps with governance" mean??? And this is where the nightmares begin!
- catinblack 4y ago
  It's not even that they are supposed to use some solutions without the approval of the IT department. The IT department could, for example, prepare some sandbox for people to play with. They can create separate systems and with their consent and approval people could "play" with ideas. I feel under the skin that there is huge room for innovation.
  - csours 4y ago
    I don't dispute that at all. This could happen. It should happen. IT has an allergic reaction to Shadow IT because they know about the times they had to deal with it. Understanding what IT has had to do in the past to fix things helps you understand why they don't think in these terms.
    - ok_dad 4y ago
      Shadow IT happens when the user isn’t getting what they need. I wrote software in excel at one job that did the priority planning for incoming inspection, because we didn’t have anything we could use to do that other than SAP and I wasn’t going to engage with that system due to effort required.
- clcaev 4y ago
  Shadow IT could be seen as ignoring externalities such as security, operational resilience, and process coherence in order to "get things done". Eventually the bill comes due (security incident, key employee exit, incorrect results). Questions are: can you recognize failure? who pays to fix it? what happens while it's being fixed?
openfuture 4y ago
I think what you are describing is basically a good development environment.. where you can contribute your insight at depth of skill level appropriate for what you have to offer. From my point of view the path to the eventually persuasive version of this enviornment (i.e. where your friend and the CTO will accept to use it at their factory) starts by setting a common standard for data interchange between the tools. So partial work can be commented on and different options for completing it can be assessed relative to one another. I'm just one person but I am on my way and datalisp.is my starting point ... I am certain that the road goes by your place on the way to prosperity.
- catinblack 4y ago
  Thanks for this vote. Good point with the standardization. I take it.

maxbond 4y ago

Have people worked in such a place where "on deck" engineers are hired out? Why wasn't there enough work to assign? How long were you contracted out for? I'm having a hard time imagining how this would work. It seems to me like it won't be very long until there's work people will need your help with, and that by the time you've gotten up to speed on things with this other company, you'll be parting ways. I have to imagine there are some interesting relationships and circumstances that align for such things to happen.

brundolf 4y ago
It's bizarre and the article is vague about it, but if I had to speculate: Tech-first companies always have more software work that can be done; if not, they come up with new work to expand the business (features, scaling, etc) But maybe this could happen at companies where software just supports the primary business? If the software isn't the product, and it's currently doing everything it needs to do for the business, I could imagine a scenario where IT people might become idle
- ChrisMarshallNY 4y ago
  I've never encountered anything like that, myself, but I have been in sort of a "silo," for most of my career. The author may be in a contract outsourcing shop.
  - brundolf 4y ago
    Yeah. This situation is entirely alien to my career, though I've also never worked at a non-tech company (hence the speculation)
- PeterisP 4y ago
  The market is quite different in different countries. It seems that where the OP is located (Poland?) the job market is dominated by "IT companies" as in large contracting shops, not "IT companies" as tech product companies employing huge numbers of in-house developers.

scotty79 4y ago

I have nothing against being called a resource and treated as such. It's a clear deal for me. I do my stuff and bear as much responsibility for your business and care for it as much as lump of iron. Any other arrangement seems to me like different flavor of "we are a family" dishonest.

trhr 4y ago

I've been writing code for 30 years, invented three algorithms, have managed engineering teams and been trusted with half-million-dollar tech budgets, but because I don't have a C.S. degree, I rarely get into a final round. Maybe changing the expectation that good developers must excel at LeetCode is a place to start fixing the shortage that causes this problem in the first place. I excel at perceiving contexts and understanding when to change approaches, but since you can't test that in a tech screen, it's basically a worthless skill to have.

vecter 4y ago
You sound like you have a really valuable experience and skillset. In your opinion, how would you go about technical interviewing in a way that makes sense?
- le-mark 4y ago
  Have a conversation with someone who can recognize the experience, and not be threatened by it. Look for the candidate to tell war stories about technical challenges, leadership challenges, interpersonal challenges and how they solved them and what they learned. Read their resume and recognize multiple stints of increasing responsibility at quality companies means something.
- ChrisMarshallNY 4y ago
  I can: A) Relate to the GP, and B) Answer the question For (B), my experience was that LeetCode was worthless, as I was looking for a senior-level engineer, to come into an established team, and start being a contributor, ASAP. I spent 25 years, hiring experienced coders, and ran an established team, that was part of a much larger, established organization. Headcount was really difficult for me to get, and the company was cheap. They were a huge name, and assumed that everyone was fighting to join the company. If you were a photographer, that was the case. If you were a programmer, that was definitely not the case. So I had a challenge. I suspect that the low-end salary chased away most people that were only looking to hop onto a short-term, salary multiplier gig. Pretty much everyone that I interviewed was serious about getting involved in some extremely interesting work (C++ image processing pipeline development). I got folks to talk about their passions and projects. The best way to figure out how folks work, is to ask them to wax eloquent on problems they've solved, and projects they wrote. I would have killed for large GitHub portfolios. I loved long résumés, and would definitely have spent a lot of time, reviewing them, if they were offered. I think I basically made good choices. There was never a technical misfit. In a couple of cases, the person couldn't integrate too well into the team. I had a very relaxed environment, and each team member had their own proclivities and workflow. We made it work; I suspect the fact that they all had decades of experience, helped. I kept people on board for decades (not an exaggeration). Remember I said that headcount was such a bitch to get? That was a big reason for me wanting to keep people. Also, the Japanese team would barely acknowledge their existence, until they had been at the company for at least a year. In my experience, someone who is good at interview tech questions, is good at interview tech questions, but that does not give me any clue, as to how they will be, when they hit some of the rather hairy (often threaded) algorithms we had. I had to take risks. If an employee did not work out for at least a couple of years, I got grief. So I got highly competent, experienced C++ engineers to join, for low-ish salaries, and I kept them, for many years. I guess that's not a valuable skill, in managers, anymore. I think I did OK. [UPDATE] I made it more about me, to try to make the comment a bit less abrasive.

vsareto 4y ago

>Good software engineers are characterized by determination and persistence, thanks to which they can deliver effective and intuitive solutions to end users. They must have a rich imagination, be up to date with industry trends, read a lot, stretch their knowledge to the limit, challenge the status quo, and go beyond their comfort zone every day. Now do the other roles around software and you'll quickly realize this is heavy idealism. And sometimes those roles are even paid more.

pipeline_peak 4y ago
The only thing I ever had to be "up to date on" was my deadline, the valued knowledge was always product specific. Idk why all this "shake things up" brogrammer Mr. Robot persona keeps buzzing by my ears, but never in my past 4 jobs have I heard "on the bench". I haven't worked at the most exciting places, but for every Google there are 10,000 DoD, Health Insurance, Asset tracking legacy-ware firms. They're workin hard, but I wouldn't quite say "challenging the status quo" lol.

TruthWillHurt 4y ago

Total fiction. In over two decades I've never seen engineers on the bench or hired out. maybe in scummy agencies, but not in proper companies.