7 ms·

> It's a race to the bottom. You could pay more for better work that gets done more slowly (fewer hours as people have families, etc,) or you could pay less for

> It's a race to the bottom. You could pay more for better work that gets done more slowly (fewer hours as people have families, etc,) or you could pay less for worse work that gets done more quickly. But in my experience, this is not true AT ALL. More experienced people might work less hours, but will produce the actual end results much quicker - both in hours and in calendar time. Especially when considering that less experienced devs will (on the average) cause more bugs and worse code structure - in the long run this causes a ton of extra work. In my opinion that is the main difference that easily makes someone a "10x" or a "100x" developer.

Cthulhu_ 9y ago
But that part - bugs, structure - quickly becomes invisible to higher management, as they start to rake in millions the software issues become only minor hitches in comparison. When a company does well, software problems are easily forgiven - Twitter had huge scaling problems but still grew to one of the largest platforms; Coinbase is having regular problems now and is a multi-billion platform. Code quality doesn't matter if the business goes well. We purists like to think that high-quality software sells itself, but I'm more and more starting to think that you can't start off with that. Of course, on the other hand over-engineering at an early phase of a project is very much a thing too - starting with microservices, using the latest framework or language, etc.
- majjam 9y ago
  Please can you explain why using microservoces is over engineering? Is it because it’s a relatively new approach? Im getting involved in a new project that is using microservices and a new framework...
  - beaconstudios 9y ago
    not OP, but microservices can cause you to have to spend a disproportionate amount of time writing glue code between services. Starting with microservices is often a case of implementing separation of concern at the network rather than the functional layer, which is IMO too high in the stack. Microservices should be extracted for performance reasons, not build from the start because they are trendy.
  - Ygg2 9y ago
    Did you read Honest status page? If you want your debugging session to reminiscent of a whodunit go with microservices. If you are doing microservices, I hope you have a good reason for doing so. Because there are significant problems with using microservices.
  - BjoernKW 9y ago
    Because like any design pattern microservices should be used to address a specific problem. Martin Fowler describes that particular design pattern here in great detail: https://martinfowler.com/articles/microservices.html https://martinfowler.com/articles/microservices.html Microservices however unfortunately have become a fashionable cure-all that's applied indiscriminately to software projects of all sizes, ages and purposes. Hardly anyone seems to be asking anymore why they're actually using microservices. Everyone uses them because everyone else does. Microservices always incur overhead both in terms of engineering and network latency as well as maintenance / administration. If you have more than 1 microservice you need infrastructure for orchestrating and monitoring these services. For all that to be worth it you need to have pretty solid arguments for using microservices in the first place. For a new project I'd usually advise against using microservices right from the start. Doing so is often rooted in the same kind of fallacy that has people worry about Facebook-scale scalability before they even have their first user. If you start having problems that can be solved with microservices then good for you! This means your software is successful and has grown so much in terms of features and responsibilities it's starting to become intractable with standard approaches. This is precisely why Martin Fowler argues for starting with a monolith first: https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html A traditional monolith gives you the opportunity to learn about the problem domain first without having to worry about implementation details such as microservices.
    - smugworth 9y ago
      I think the strategy of "monolith first" isn't a poor one, but it is a little humorous to see someone who makes part of their living helping companies break apart their monoliths advocate it.
      - mbrameld 9y ago
        I guess. My partner is currently starting a mushroom farm. She hopes one day it will be big enough to make use of a very large facility. Right now it isn't, though. Do you find the same humor in her real estate broker guiding her towards smaller properties initially even though if her business successfully grows the broker will make part of their living helping her move into a bigger location? Makes perfect sense to me.
  - sudhirj 9y ago
    They work well when designed well - and for me that's more often designed organically. If they're designed badly, most bugs eventually reduce to trying to do distributed transactions across microservices. That's my yardstick - if I see poor man's distributed transaction attempts happening across service boundaries I'll start to assume over-engineering / cargo culting. If I see services acting a nodes in an pipeline or a flowchart, preferably with multiple incoming lines, it smells better to me.
scarface74 9y ago
And twitter became a successful (questionable) company with buggy code and the infamous "fail whale". You don't need good code, you sometimes just need shippable code to get by until the company executes on their exit strategy.
- gdilla 9y ago
  Hasn't Twitter racked up 2.5B in losses and yet to turn a profit (though reportedly close to doing it for the first time ever). 2.5B in losses for a platform you could build and scale for what, $10M now. Very questionably successful - some people got rich so yes, i suppose?
  - geekamongus 9y ago
    It's now the platform for official communications from the US Government's Executive Branch, so you can expect it to worsen based on red tape alone.
  - scarface74 9y ago
    That's why I added (questionable). I've made the mistake at one company of thinking that my job was to architect solid software that was sustainable for the long term. What they really wanted was to have software that was "good enough" and had all of the checkbox features to be attractive to potential acquirers so the investors would stop breathing down their necks.
    - candiodari 9y ago
      Twitter "made 2.5B losses". Yeah ... that's bad ... but not from the perspectives of investors. Jack Dorsey became a billionaire from those losses. The same is true for probably all other early investors. For an investment in Twitter to have done really badly, there was a "bear" period of about 2 years. And before you say it, remember that even Google stock dropped 60%, Facebook's 70%. Twitter's drop actually looks pretty reasonable in comparison. So firstly, I don't think twitter is bad, and secondly, I don't think people have given up on twitter, and thirdly, that seems pretty justified.
nostrademons 9y ago
In most companies upper management can change their mind faster than junior developers can write bugs, thus invalidating all the buggy code already written.
- le-mark 9y ago
  Literally laughed out loud. So many times, I've sat on requirements or even projects waiting for the inevitable "change of priorities" making the projects no longer relevant. "Forget X, Y is the new priority", it's very reliable in big dumb corporations.
at-fates-hands 9y ago
>> less experienced devs will (on the average) cause more bugs and worse code structure - in the long run this causes a ton of extra work. In the last five years or so, I've done contract work at several large corporations. In every single one, they didn't care about defects or code structure. They just wanted to ship an application in a very short period of time. When I asked about the same thing you pointed out, the response was the same, "We don't care about defects once it's released, and we don't care what the code looks like. It needs to work well for our end users, nothing else. Besides, in 6 months, we're going to redesign and rebuild it anyways." It just seems nobody cares about long term maintenance, and likewise, they don't care much about the code or the amount of defects that code is generating. Pretty maddening when you think about it. Nobody cares about quality anymore.
- sbmassey 9y ago
  If they actually redesigned and rebuilt it evety 6 months, that would be a reasonable approach. Often they just want to build more stuff on top of what they already have, however.
- candiodari 9y ago
  That may simply mean that only one of these things really is quality : 1) working great and well for the end user, for the function of the software 2) bugs and code structure Code quality can be so bad that it matters. But beyond a basic level, it does not matter. Bad code that works beats great code that doesn't fulfill it's function every single time. I once had this great lesson. I was brought into a team as a TL/Manager. We were making a product that was doing pretty well, in terms of attention it was getting and so on. 1 week in, I learn that about 70% of the code is tests, 30% is actual code that's used at runtime. 2 weeks in I learn that everybody's always working on the tests, never on the program (there's a reasonably good reason for this even). 3 weeks in I explore the program, and at some point I try to run it. Turns out the "main" function is broken. Because of crashes (plural) during variable initialization it never gets to the first line of the main function ... How long had these bugs existed (it wasn't just one), you ask ? Well, over 3 months. Doesn't happen in the (VERY extensive) test run. Lessons learned in that project: 1) test driven development is a great place to start, and a VERY bad way to run projects once they're even 10% into their delivery schedule 2) even the best tests don't check everything 3) even the best tests don't guarantee that even the most basic simple parts of the program work. In fact, tests actually WORK AGAINST THIS. 4) the value of a system test (where the entire program runs, by actually going into main and doing what it's supposed to on a realistic example) is incredible. The criticism that TDD developers have is valid, that if it fails you won't know (necessarily) where it failed, but isn't that serious. Firstly, you'll usually have some idea of where it failed, and secondly, and this is the big one, you'll know it fails. FAR preferable to the other situation. They're also very hard to write. Tough. You need them, far more than you need unit tests on 5 line functions. 5) you are MUCH better off with a "hero" programmer (bad name, "loose cannon" would be more apt description) AND someone acting 90% anal about tests, and managing the inevitable conflict, than you are without the loose cannon. Managing that conflict will be a challenge though. And yes, that means that, to the utter dismay of the TDD developer, you'll have to tell him to let in code without, or with bad tests, from time to time.
heedlessly2 9y ago
a 24 year old from a top CS college with 3 years of solid javascript experience will be better than a 40 year old with 15+ years of C#.net experience for today's job market
- JustSomeNobody 9y ago
  If you live on the web, maybe this is your perspective. There's a whole 'nother world out there than just the web.
- ycombobreaker 9y ago
  What about a 36 year old from a top CS college with 6 years of Java experience, 6 years of C#, and 3 years of Javascript? And many more failures and paradigm shifts under their belt, by the way. The core field of undergraduate CS hasn't changed much in the past decade, mostly there are new options for specialization and the bleeding edge remains in graduate programs. If you still think the 24 year old is the superior choice, then even generously you're not looking for skill.
wef23f 9y ago
That's your take from the trenches. The filter layer above isn't tuned to that message. It's tuned to a message from bean counters/upper management.

Cthulhu_ 9y ago

But that part - bugs, structure - quickly becomes invisible to higher management, as they start to rake in millions the software issues become only minor hitches in comparison. When a company does well, software problems are easily forgiven - Twitter had huge scaling problems but still grew to one of the largest platforms; Coinbase is having regular problems now and is a multi-billion platform. Code quality doesn't matter if the business goes well. We purists like to think that high-quality software sells itself, but I'm more and more starting to think that you can't start off with that. Of course, on the other hand over-engineering at an early phase of a project is very much a thing too - starting with microservices, using the latest framework or language, etc.

majjam 9y ago
Please can you explain why using microservoces is over engineering? Is it because it’s a relatively new approach? Im getting involved in a new project that is using microservices and a new framework...
- beaconstudios 9y ago
  not OP, but microservices can cause you to have to spend a disproportionate amount of time writing glue code between services. Starting with microservices is often a case of implementing separation of concern at the network rather than the functional layer, which is IMO too high in the stack. Microservices should be extracted for performance reasons, not build from the start because they are trendy.
- Ygg2 9y ago
  Did you read Honest status page? If you want your debugging session to reminiscent of a whodunit go with microservices. If you are doing microservices, I hope you have a good reason for doing so. Because there are significant problems with using microservices.
- BjoernKW 9y ago
  Because like any design pattern microservices should be used to address a specific problem. Martin Fowler describes that particular design pattern here in great detail: https://martinfowler.com/articles/microservices.html https://martinfowler.com/articles/microservices.html Microservices however unfortunately have become a fashionable cure-all that's applied indiscriminately to software projects of all sizes, ages and purposes. Hardly anyone seems to be asking anymore why they're actually using microservices. Everyone uses them because everyone else does. Microservices always incur overhead both in terms of engineering and network latency as well as maintenance / administration. If you have more than 1 microservice you need infrastructure for orchestrating and monitoring these services. For all that to be worth it you need to have pretty solid arguments for using microservices in the first place. For a new project I'd usually advise against using microservices right from the start. Doing so is often rooted in the same kind of fallacy that has people worry about Facebook-scale scalability before they even have their first user. If you start having problems that can be solved with microservices then good for you! This means your software is successful and has grown so much in terms of features and responsibilities it's starting to become intractable with standard approaches. This is precisely why Martin Fowler argues for starting with a monolith first: https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html A traditional monolith gives you the opportunity to learn about the problem domain first without having to worry about implementation details such as microservices.
  - smugworth 9y ago
    I think the strategy of "monolith first" isn't a poor one, but it is a little humorous to see someone who makes part of their living helping companies break apart their monoliths advocate it.
    - mbrameld 9y ago
      I guess. My partner is currently starting a mushroom farm. She hopes one day it will be big enough to make use of a very large facility. Right now it isn't, though. Do you find the same humor in her real estate broker guiding her towards smaller properties initially even though if her business successfully grows the broker will make part of their living helping her move into a bigger location? Makes perfect sense to me.
- sudhirj 9y ago
  They work well when designed well - and for me that's more often designed organically. If they're designed badly, most bugs eventually reduce to trying to do distributed transactions across microservices. That's my yardstick - if I see poor man's distributed transaction attempts happening across service boundaries I'll start to assume over-engineering / cargo culting. If I see services acting a nodes in an pipeline or a flowchart, preferably with multiple incoming lines, it smells better to me.

scarface74 9y ago

And twitter became a successful (questionable) company with buggy code and the infamous "fail whale". You don't need good code, you sometimes just need shippable code to get by until the company executes on their exit strategy.

gdilla 9y ago
Hasn't Twitter racked up 2.5B in losses and yet to turn a profit (though reportedly close to doing it for the first time ever). 2.5B in losses for a platform you could build and scale for what, $10M now. Very questionably successful - some people got rich so yes, i suppose?
- geekamongus 9y ago
  It's now the platform for official communications from the US Government's Executive Branch, so you can expect it to worsen based on red tape alone.
- scarface74 9y ago
  That's why I added (questionable). I've made the mistake at one company of thinking that my job was to architect solid software that was sustainable for the long term. What they really wanted was to have software that was "good enough" and had all of the checkbox features to be attractive to potential acquirers so the investors would stop breathing down their necks.
  - candiodari 9y ago
    Twitter "made 2.5B losses". Yeah ... that's bad ... but not from the perspectives of investors. Jack Dorsey became a billionaire from those losses. The same is true for probably all other early investors. For an investment in Twitter to have done really badly, there was a "bear" period of about 2 years. And before you say it, remember that even Google stock dropped 60%, Facebook's 70%. Twitter's drop actually looks pretty reasonable in comparison. So firstly, I don't think twitter is bad, and secondly, I don't think people have given up on twitter, and thirdly, that seems pretty justified.

nostrademons 9y ago

In most companies upper management can change their mind faster than junior developers can write bugs, thus invalidating all the buggy code already written.

le-mark 9y ago
Literally laughed out loud. So many times, I've sat on requirements or even projects waiting for the inevitable "change of priorities" making the projects no longer relevant. "Forget X, Y is the new priority", it's very reliable in big dumb corporations.

at-fates-hands 9y ago

>> less experienced devs will (on the average) cause more bugs and worse code structure - in the long run this causes a ton of extra work. In the last five years or so, I've done contract work at several large corporations. In every single one, they didn't care about defects or code structure. They just wanted to ship an application in a very short period of time. When I asked about the same thing you pointed out, the response was the same, "We don't care about defects once it's released, and we don't care what the code looks like. It needs to work well for our end users, nothing else. Besides, in 6 months, we're going to redesign and rebuild it anyways." It just seems nobody cares about long term maintenance, and likewise, they don't care much about the code or the amount of defects that code is generating. Pretty maddening when you think about it. Nobody cares about quality anymore.

sbmassey 9y ago
If they actually redesigned and rebuilt it evety 6 months, that would be a reasonable approach. Often they just want to build more stuff on top of what they already have, however.
candiodari 9y ago
That may simply mean that only one of these things really is quality : 1) working great and well for the end user, for the function of the software 2) bugs and code structure Code quality can be so bad that it matters. But beyond a basic level, it does not matter. Bad code that works beats great code that doesn't fulfill it's function every single time. I once had this great lesson. I was brought into a team as a TL/Manager. We were making a product that was doing pretty well, in terms of attention it was getting and so on. 1 week in, I learn that about 70% of the code is tests, 30% is actual code that's used at runtime. 2 weeks in I learn that everybody's always working on the tests, never on the program (there's a reasonably good reason for this even). 3 weeks in I explore the program, and at some point I try to run it. Turns out the "main" function is broken. Because of crashes (plural) during variable initialization it never gets to the first line of the main function ... How long had these bugs existed (it wasn't just one), you ask ? Well, over 3 months. Doesn't happen in the (VERY extensive) test run. Lessons learned in that project: 1) test driven development is a great place to start, and a VERY bad way to run projects once they're even 10% into their delivery schedule 2) even the best tests don't check everything 3) even the best tests don't guarantee that even the most basic simple parts of the program work. In fact, tests actually WORK AGAINST THIS. 4) the value of a system test (where the entire program runs, by actually going into main and doing what it's supposed to on a realistic example) is incredible. The criticism that TDD developers have is valid, that if it fails you won't know (necessarily) where it failed, but isn't that serious. Firstly, you'll usually have some idea of where it failed, and secondly, and this is the big one, you'll know it fails. FAR preferable to the other situation. They're also very hard to write. Tough. You need them, far more than you need unit tests on 5 line functions. 5) you are MUCH better off with a "hero" programmer (bad name, "loose cannon" would be more apt description) AND someone acting 90% anal about tests, and managing the inevitable conflict, than you are without the loose cannon. Managing that conflict will be a challenge though. And yes, that means that, to the utter dismay of the TDD developer, you'll have to tell him to let in code without, or with bad tests, from time to time.

heedlessly2 9y ago

a 24 year old from a top CS college with 3 years of solid javascript experience will be better than a 40 year old with 15+ years of C#.net experience for today's job market

JustSomeNobody 9y ago
If you live on the web, maybe this is your perspective. There's a whole 'nother world out there than just the web.
ycombobreaker 9y ago
What about a 36 year old from a top CS college with 6 years of Java experience, 6 years of C#, and 3 years of Javascript? And many more failures and paradigm shifts under their belt, by the way. The core field of undergraduate CS hasn't changed much in the past decade, mostly there are new options for specialization and the bleeding edge remains in graduate programs. If you still think the 24 year old is the superior choice, then even generously you're not looking for skill.

wef23f 9y ago

That's your take from the trenches. The filter layer above isn't tuned to that message. It's tuned to a message from bean counters/upper management.