The 10X Programmer

  • I've met a couple, but I think they are rare. I think I work with one now, though maybe he's more a 10x IT person. Amazed how much, how quickly, and how well he gets things done.

    I do get to work with some that I think are 3-4x from the average, getting a lot more done, but 10 is a huge leap. Mostly, I think that the 10x people are those that might produce work at the same speed, or slightly slower/faster, but they have 10x less reasons to ever touch their code again.

  • Jeff Moden wrote:

    skeleton567 wrote:

    The greatest danger of a '10x programmer' or a 'superstar programmer' is WHO THINKS THEY ARE SUCH.

    +1 Billion for that comment!!!

    I hope I am not that arrogant to think I am a 10x programmer. I judge my self to be a good programmer that produces as close to bug free tested code to QA. Heck I'm not sure I'm better than a 1x DBA 🙂

    Far away is close at hand in the images of elsewhere.
    Anon.

  • 5 developers (actually more, but 5 was a typical number of SQL developers on roster at the same time) developed a system with weekly -partitioned transaction tables. It was a set of tables with week numbers embedded in their names.

    6 hour long data upload process included recreating views to use for reporting monthly, 3 months, etc. aggregations, recreating procedures which now have to use data from appropriate newly created weekly tables along from predefined number of tables from prior weeks.

    Reporting and data processing queries caused a lot of locking and deadlocking, which led to creating 9 replications transferring data to other databases on the same and another server.

    I redeveloped the core transactional table eliminating the weekly partitioning, reduced 6 hour upload duration to 20-30 minutes, eliminated the need for 6 replications and several other "data massaging" processes, and was on the way to drop 2 databases of 8 TB in total, because they held redundant data coming from those data preparation processes.

    The set of reports which were taking 3+ hours to complete now could be done in 30 minutes.

    how much of a programmer I turned out to be?

    ok, not 10x, but at least 5x?

    Well, at least 1x?

    No, it must have been a negative number.

    Actually they were so proud of all those terabytes, their management have been bragging about those MB/s their super fancy servers were processing. And my improvements just ruined their party.

    They never needed more effective solutions, they were happy with crappy sql programmers who created wasteful system, which allowed them to justify big expenses on IT, effectively milking the big and rich customer.

    With more business acquired by big corporations this pattern becomes more and more typical. IT management don't want better and more effective solutions, they need more action based on commonly used "best practices", so their department can take a bigger chunk of the general business.

    _____________
    Code for TallyGenerator

  • Sergiy wrote:

    5 developers (actually more, but 5 was a typical number of SQL developers on roster at the same time) developed a system with weekly -partitioned transaction tables. It was a set of tables with week numbers embedded in their names.

    6 hour long data upload process included recreating views to use for reporting monthly, 3 months, etc. aggregations, recreating procedures which now have to use data from appropriate newly created weekly tables along from predefined number of tables from prior weeks.

    Reporting and data processing queries caused a lot of locking and deadlocking, which led to creating 9 replications transferring data to other databases on the same and another server.

    I redeveloped the core transactional table eliminating the weekly partitioning, reduced 6 hour upload duration to 20-30 minutes, eliminated the need for 6 replications and several other "data massaging" processes, and was on the way to drop 2 databases of 8 TB in total, because they held redundant data coming from those data preparation processes.

    The set of reports which were taking 3+ hours to complete now could be done in 30 minutes.

    how much of a programmer I turned out to be?

    ok, not 10x, but at least 5x?

    Well, at least 1x?

    No, it must have been a negative number.

    Actually they were so proud of all those terabytes, their management have been bragging about those MB/s their super fancy servers were processing. And my improvements just ruined their party.

    They never needed more effective solutions, they were happy with crappy sql programmers who created wasteful system, which allowed them to justify big expenses on IT, effectively milking the big and rich customer.

    With more business acquired by big corporations this pattern becomes more and more typical. IT management don't want better and more effective solutions, they need more action based on commonly used "best practices", so their department can take a bigger chunk of the general business.

     

    OK, this is a great example of how you can BE a 10x developer.  There is a term that applies to what is needed here, and it is 'absorption'.   A 10x developer will consider the 'rate of absorption' in the design of data movement, especially for larger quantities.  Perhaps a weekly move of a large quantity of data needs to be broken down into a daily, or even sub-daily timeframes to control the effect on the receiving server and its other processes.  Transaction sizes and lengths do need to be controlled.

    Think about the process of watering a flower planter.  You may need to add a gallon of water to a large pot, but if you pour it on all at once it will run over the rim.  But if you add a pint at a time, it will soak in and actually reach the plant.

    Yes, sometimes we need to think 'smaller' instead of  'larger'.  Even reporting queries may need to be broken down into segments which move the data in smaller chunks to another location to be sorted, indexed, whatever for the reporting, and then disposed of.

     

    Rick
    Disaster Recovery = Backup ( Backup ( Your Backup ) )

  • Sergiy wrote:

    ...they need more action based on commonly used "best practices"...

    Heh... allow me to reword that for you my long time friend in arms....

    ...they need more action based on commonly used "best mis-practices"...

    😀

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 5 posts - 46 through 49 (of 49 total)

You must be logged in to reply to this topic. Login to reply