4 ms·

so much of this hit home. I'm disorganized. I like to just get at the meat of the problem. I don't sit on my hands shopping for programming patterns to use. I

so much of this hit home. I'm disorganized. I like to just get at the meat of the problem. I don't sit on my hands shopping for programming patterns to use. I compare the process of creating software much like pottery when you start out with clay it's not clear what the end result is going to be. But as you play around with it something forms, and you impose more structure and clear cut features with refactoring. type b coders like us get a lot of shit for eccentric decisions that ultimately lead to breakthrough ideas or features but type A coders is almost always dominating with logic and aggression I see tensions between developers. If what the article says holds true, I would say Type A coders are more for maintenance and Type B coders are the visionaries. Type B is the engineer that gets paid millions for writing MVPs as a early CTO while Type A engineers tendency to compete on everything leads to burn out and lower salary. Likewise Type B would be horrible in a corporate environment where as Type A would do well.

n72 11y ago
Yup, you type B's are glorious, righteous, and so often misunderstood people. We, type A's, are pretty much only good for writing unit tests.
- jorgecurio 11y ago
  you left out that type B's are also disorganized and messy and I never said type B are glorious and righteous. Like the article says nobody is right or wrong. I just simply put the case out there that one personality is a good fit for different stages of the company.
sanderjd 11y ago
This is an extremely high-and-mighty perspective. If this is truly your worldview, you may do well to take a step back and consider upping your humility and compassion levels. Next time someone gives you shit for your eccentric decisions, maybe try really asking yourself whether they might be right and you might be wrong. Next time you see somebody reading up on programming techniques and best practices, maybe consider that they might be wisely availing themselves of learning resources beyond themselves, rather than "sit[ting] on [their] hands". I do agree with you that the tendency to compete to be the most "right" is a problem amongst programmers, but I don't really see that it fits into this whole (contrived, IMO) "Type A" vs. "Type B" thing. I've seen plenty of bikeshedding amongst the organized and the disorganized alike.
- jorgecurio 11y ago
  >The type A programmers are right that correctness and uniformity is important for building robust, maintainable software. The type B programmers are right that a tight feedback loop and experimentation is important for building simple, innovative software. Almost early on in any startup phase, you want a type B to quickly build MVP without drama and then hiring type A to refactor it. I've seen a startup get all worked up about structures, spacings, unit tests when they don't even have a customer yet, can't ship fast enough because of all these bottlenecks introduced by Type A architect. In large corporation Type A would thrive where as the Type B wouldn't so I just don't see why you take what I said to the heart.
  - sanderjd 11y ago
    I really didn't take what you said "to the heart". I was more hoping to nudge you toward a greater self awareness. (I'm also being pretty high-and-mighty by thinking that's my prerogative, so there we are.) The truth of the matter is that knowing when and how to build an MVP quickly without wasting time on the wrong things and knowing when and how to create reliable and maintainable software is all part of your job as a software developer. Choosing one or the other as "that's just how I am" is shirking responsibility.
pka 11y ago
More likely, your "type B" programmer will build a half-assed MVP with 20% of the initial features that will break every 5 seconds and thus the "million dollars paying startup" will lose their customers to the saner competition. I will also very much question your visionaries/maintenance distinction. Many dynamic languages today are influenced by technology developed in academia. This is because the "type B coder" you are speaking of lacks the theoretical foundation to build sound abstractions that are proven to not break. I would describe myself very much as a "type B" personality - I'm completely disorganized, messy and lazy. I've event gotten into (physical) fights with flatmates over this. And precisely because of this, I'm choosing technology that takes away all the rigid bookkeeping and context switching that is needed when writing anything more complex than a basic Bootstrap/Angular/whatever bullshit CRUD app. This is because refactoring is a lot harder in a language without structure. I would never dare rip out the base data structures and replace them with something completely different in a project with more than 2kloc in a language without types. While in a logically sound language I do that daily and don't even care - a perfect fit for my "type B" personality.

n72 11y ago

Yup, you type B's are glorious, righteous, and so often misunderstood people. We, type A's, are pretty much only good for writing unit tests.

jorgecurio 11y ago
you left out that type B's are also disorganized and messy and I never said type B are glorious and righteous. Like the article says nobody is right or wrong. I just simply put the case out there that one personality is a good fit for different stages of the company.

sanderjd 11y ago

This is an extremely high-and-mighty perspective. If this is truly your worldview, you may do well to take a step back and consider upping your humility and compassion levels. Next time someone gives you shit for your eccentric decisions, maybe try really asking yourself whether they might be right and you might be wrong. Next time you see somebody reading up on programming techniques and best practices, maybe consider that they might be wisely availing themselves of learning resources beyond themselves, rather than "sit[ting] on [their] hands". I do agree with you that the tendency to compete to be the most "right" is a problem amongst programmers, but I don't really see that it fits into this whole (contrived, IMO) "Type A" vs. "Type B" thing. I've seen plenty of bikeshedding amongst the organized and the disorganized alike.

jorgecurio 11y ago
>The type A programmers are right that correctness and uniformity is important for building robust, maintainable software. The type B programmers are right that a tight feedback loop and experimentation is important for building simple, innovative software. Almost early on in any startup phase, you want a type B to quickly build MVP without drama and then hiring type A to refactor it. I've seen a startup get all worked up about structures, spacings, unit tests when they don't even have a customer yet, can't ship fast enough because of all these bottlenecks introduced by Type A architect. In large corporation Type A would thrive where as the Type B wouldn't so I just don't see why you take what I said to the heart.
- sanderjd 11y ago
  I really didn't take what you said "to the heart". I was more hoping to nudge you toward a greater self awareness. (I'm also being pretty high-and-mighty by thinking that's my prerogative, so there we are.) The truth of the matter is that knowing when and how to build an MVP quickly without wasting time on the wrong things and knowing when and how to create reliable and maintainable software is all part of your job as a software developer. Choosing one or the other as "that's just how I am" is shirking responsibility.

pka 11y ago

More likely, your "type B" programmer will build a half-assed MVP with 20% of the initial features that will break every 5 seconds and thus the "million dollars paying startup" will lose their customers to the saner competition. I will also very much question your visionaries/maintenance distinction. Many dynamic languages today are influenced by technology developed in academia. This is because the "type B coder" you are speaking of lacks the theoretical foundation to build sound abstractions that are proven to not break. I would describe myself very much as a "type B" personality - I'm completely disorganized, messy and lazy. I've event gotten into (physical) fights with flatmates over this. And precisely because of this, I'm choosing technology that takes away all the rigid bookkeeping and context switching that is needed when writing anything more complex than a basic Bootstrap/Angular/whatever bullshit CRUD app. This is because refactoring is a lot harder in a language without structure. I would never dare rip out the base data structures and replace them with something completely different in a project with more than 2kloc in a language without types. While in a logically sound language I do that daily and don't even care - a perfect fit for my "type B" personality.