5 ms·

Coding isn't the hard part, it's business logic.

brianwawok 4y ago
Eh. Writing code that is maintainable and bug free is a skill. Meeting the acceptance criteria with guess and check isn’t hard.
- jsiaajdsdaa 4y ago
  Imagine having good ACs, or any ACs at all. Wouldn't be me!
- pdimitar 4y ago
  Hardest yet: apply professional rigor and be actually given time to do so because apparently just hacking something together that looks to work is the best thing ever (in the eyes of managers and business owners).
- trention 4y ago
  >Meeting the acceptance criteria with guess and check isn’t hard. Acceptance criteria often don't exist or are wrong. Incidentally, when someone says "business requirements are easy", that's a pretty big tell they have never worked on a complicated project.
  - mgkimsal 4y ago
    > that's a pretty big tell they have never worked on a complicated project. Even an 'easy' project, it's not easy. Edge cases, security, performance, dealing with error conditions, dealing with bad external vendor/data. "We'll just import data from vendor X". Yeah, that can never go wrong!
- kube-system 4y ago
  Software engineering is a well understood science in many cultures. Parsing acceptance criteria written by someone of another culture and domain experience can be difficult for some, and it’s not something learned in computer science courses.
makeitdouble 4y ago
Working for a while in a very small team, outsourcing has been discussed a lot. What stopped us every time was the coding part. Imagine having perfect business requirements, and preparing perfect acceptance tests. Once your feature is delivered you safely ship, and after a week or two come up with improvements. You prepare to redo the cycle, except your outsourcing firm is busy and you need to ask elsewhere. They come up for twice the expected price and want to rewrite half of the logic. From there, it will basically cost more and more each time to make the feature evolve, as arguably it will have become complex and touched by many hands. A solution to that is to keep a stable outsourced team. Except it’s not actually stable, people come and go and quality vary. Either way you keep someone on your team busy making sure you don’t get screwed. More often than not, that person has coding skills, that could be used to actually clean code the feature instead. Basically, outsourcing only made sense if we had no way to hire more at any reasonable price, or for one-shot project with no future behind.
- vbezhenar 4y ago
  Why do you think that you can hire stable team in your country, but you can't do that in a distant country? Seems that problem roots in those "outsourcing companies". Avoid those companies then. Hire directly.
  - pixl97 4y ago
    I think that is still a middle layer problem. A root layer problem would be "pay your developers enough they don't leave", but that in general is in conflict with business practices optimized to make as much profit as possible next quarter.
  - makeitdouble 4y ago
    Setting up a payroll in a different country is a lot more effort than what most companies want. You can do consulting contracts instead, but it then becomes harder to find people who want long term contracts for single clients (those people need a solid reason to not choose a local company or a bigger global company that has a full payroll in their countries). Not considering you have to do the hiring in the first place. It’s not intractable, but we wouldn’t have been hiring full remote teams of 10 or 20 people so the effort doesn’t scale much, and the price difference really isn’t worth the hassle. PS: looking back at the last 2 years, many employees have looked at moving long term to another country while keeping their current jobs. I’m pretty sure even in these cases (= established relationship, proven skillset etc.) most companies bailed on dealing with the international ongoing paperwork.
drieddust 4y ago
IMHO idiomatic defensive coding is very hard.

Eh. Writing code that is maintainable and bug free is a skill. Meeting the acceptance criteria with guess and check isn’t hard.

jsiaajdsdaa 4y ago
Imagine having good ACs, or any ACs at all. Wouldn't be me!
pdimitar 4y ago
Hardest yet: apply professional rigor and be actually given time to do so because apparently just hacking something together that looks to work is the best thing ever (in the eyes of managers and business owners).
trention 4y ago
>Meeting the acceptance criteria with guess and check isn’t hard. Acceptance criteria often don't exist or are wrong. Incidentally, when someone says "business requirements are easy", that's a pretty big tell they have never worked on a complicated project.
- mgkimsal 4y ago
  > that's a pretty big tell they have never worked on a complicated project. Even an 'easy' project, it's not easy. Edge cases, security, performance, dealing with error conditions, dealing with bad external vendor/data. "We'll just import data from vendor X". Yeah, that can never go wrong!
kube-system 4y ago
Software engineering is a well understood science in many cultures. Parsing acceptance criteria written by someone of another culture and domain experience can be difficult for some, and it’s not something learned in computer science courses.

makeitdouble 4y ago

Working for a while in a very small team, outsourcing has been discussed a lot. What stopped us every time was the coding part. Imagine having perfect business requirements, and preparing perfect acceptance tests. Once your feature is delivered you safely ship, and after a week or two come up with improvements. You prepare to redo the cycle, except your outsourcing firm is busy and you need to ask elsewhere. They come up for twice the expected price and want to rewrite half of the logic. From there, it will basically cost more and more each time to make the feature evolve, as arguably it will have become complex and touched by many hands. A solution to that is to keep a stable outsourced team. Except it’s not actually stable, people come and go and quality vary. Either way you keep someone on your team busy making sure you don’t get screwed. More often than not, that person has coding skills, that could be used to actually clean code the feature instead. Basically, outsourcing only made sense if we had no way to hire more at any reasonable price, or for one-shot project with no future behind.

vbezhenar 4y ago
Why do you think that you can hire stable team in your country, but you can't do that in a distant country? Seems that problem roots in those "outsourcing companies". Avoid those companies then. Hire directly.
- pixl97 4y ago
  I think that is still a middle layer problem. A root layer problem would be "pay your developers enough they don't leave", but that in general is in conflict with business practices optimized to make as much profit as possible next quarter.
- makeitdouble 4y ago
  Setting up a payroll in a different country is a lot more effort than what most companies want. You can do consulting contracts instead, but it then becomes harder to find people who want long term contracts for single clients (those people need a solid reason to not choose a local company or a bigger global company that has a full payroll in their countries). Not considering you have to do the hiring in the first place. It’s not intractable, but we wouldn’t have been hiring full remote teams of 10 or 20 people so the effort doesn’t scale much, and the price difference really isn’t worth the hassle. PS: looking back at the last 2 years, many employees have looked at moving long term to another country while keeping their current jobs. I’m pretty sure even in these cases (= established relationship, proven skillset etc.) most companies bailed on dealing with the international ongoing paperwork.

drieddust 4y ago

IMHO idiomatic defensive coding is very hard.