4 ms·

One doesn't need to know how to code to know if a programmer delivers or is always making excuses.

by jshen 16y ago

ojbyrne 16y ago
You should probably google "Technical Debt."
- jshen 16y ago
  I've been developing software for a long time and know what technical debt is. I've seen CEOs with no coding experience effectively judge programmers. I was surprised the first time I saw it, but trust me the good ones can do it.
  - tuhin 16y ago
    Agree with you on this one! I know people who themselves cannot program but know what the hell loops are and stuff that you learn when you open a basic programming books. The stuff that tells you what the hell complexity of a program. If I were to tell them write a simple for loop they would not end up doing it, but when the programmers tell them that some task is taking time, they break down each task so logically that they would make a damn great programmer themselves. Every reason is analysed and possible directions put infront of the developers. If they say the servers we are using are not fast enough, they are quick to ask back, if it is the code or the servers themselves, since they know of people who are doing just fine using the same servers. Another great thing in a company is that there will always be smarter developers who will do the same task effectively and faster. Then of course it becomes quite evident if the other guy was at fault or had a genuine issue.
kingkilr 16y ago
One does need to be a programmer to know if they're delivering at the expense of absurd amounts of technical debt.
- jshen 16y ago
  only in the short term. In the long run that will become clear to an intelligent person.
  - kingkilr 16y ago
    Is there before or after you've taken on VC, planned a project roadmap, and realized there was no way you'd hit your goals?
    - jshen 16y ago
      we all know that software is an iterative process and that our goals, scopes, and deadlines go through a lot of change as we iterate. We know this is simply how it is. Why then is it so hard to view managing people in the same light?
moonpolysoft 16y ago
I'm going to go out on a limb here and speculate that you may be "seeking technical cofounder."
- jshen 16y ago
  I've been developing software for a long time. I'm saying this as a someone who has been a technical cofounder and watched the CEO judge me without being a coder himself. I was very surprised at how effective he was at doing that. Btw, there is a giant flaw in your logic. You assumed I couldn't judge a programmer, but you then assumed I would successfully judge a technical cofounder.
  - deleted 16y ago
    [deleted]
  - ojbyrne 16y ago
    I have also been developing software for a long time. What I learned at digg is that technical debt matters more, and becomes more of an immediate problem, if you grow insanely. If you have a 100 sympathetic people using your app, it doesn't really matter if there's a few rough edges in it. If you go from 100 sympathetic people to a million or so in six months, you go from "work on it as you can" to "we will be screwed if its not fixed immediately." Even more so, if you end up being an acquisition target for companies like Google and Yahoo (who want to read your code), then it becomes "this will cost us hundreds of millions of dollars this week if its not fixed now."
    - jshen 16y ago
      This is a bit of a tangent from the original issue which was about the ability of a non programmer to judge programmers. I still hold that the good ones can, and if they cant then how do you propose they pick their technical cofounder? Regarding technical debt, I think we're conflating a few things under this umbrella. There can be code that is easy to read and maintain, but won't scale to millions of users. Then there is spaghetti code which is brittle, hard to read and modify, but may or may not scale. I think it's ok to have the first before you know if you need to scale. When you guys got to the point that you realized it needed to scale was it fixed immediately? If not, would it have been that hard to fix it then. Btw, thank you for talking about this stuff. It's great to hear insights from someone that's been through such things.

One doesn't need to know how to code to know if a programmer delivers or is always making excuses.

by jshen 16y ago

One doesn't need to know how to code to know if a programmer delivers or is always making excuses.

ojbyrne 16y ago

You should probably google "Technical Debt."

jshen 16y ago
I've been developing software for a long time and know what technical debt is. I've seen CEOs with no coding experience effectively judge programmers. I was surprised the first time I saw it, but trust me the good ones can do it.
- tuhin 16y ago
  Agree with you on this one! I know people who themselves cannot program but know what the hell loops are and stuff that you learn when you open a basic programming books. The stuff that tells you what the hell complexity of a program. If I were to tell them write a simple for loop they would not end up doing it, but when the programmers tell them that some task is taking time, they break down each task so logically that they would make a damn great programmer themselves. Every reason is analysed and possible directions put infront of the developers. If they say the servers we are using are not fast enough, they are quick to ask back, if it is the code or the servers themselves, since they know of people who are doing just fine using the same servers. Another great thing in a company is that there will always be smarter developers who will do the same task effectively and faster. Then of course it becomes quite evident if the other guy was at fault or had a genuine issue.

kingkilr 16y ago

One does need to be a programmer to know if they're delivering at the expense of absurd amounts of technical debt.

jshen 16y ago
only in the short term. In the long run that will become clear to an intelligent person.
- kingkilr 16y ago
  Is there before or after you've taken on VC, planned a project roadmap, and realized there was no way you'd hit your goals?
  - jshen 16y ago
    we all know that software is an iterative process and that our goals, scopes, and deadlines go through a lot of change as we iterate. We know this is simply how it is. Why then is it so hard to view managing people in the same light?

moonpolysoft 16y ago

I'm going to go out on a limb here and speculate that you may be "seeking technical cofounder."

jshen 16y ago
I've been developing software for a long time. I'm saying this as a someone who has been a technical cofounder and watched the CEO judge me without being a coder himself. I was very surprised at how effective he was at doing that. Btw, there is a giant flaw in your logic. You assumed I couldn't judge a programmer, but you then assumed I would successfully judge a technical cofounder.
- deleted 16y ago
  [deleted]
- ojbyrne 16y ago
  I have also been developing software for a long time. What I learned at digg is that technical debt matters more, and becomes more of an immediate problem, if you grow insanely. If you have a 100 sympathetic people using your app, it doesn't really matter if there's a few rough edges in it. If you go from 100 sympathetic people to a million or so in six months, you go from "work on it as you can" to "we will be screwed if its not fixed immediately." Even more so, if you end up being an acquisition target for companies like Google and Yahoo (who want to read your code), then it becomes "this will cost us hundreds of millions of dollars this week if its not fixed now."
  - jshen 16y ago
    This is a bit of a tangent from the original issue which was about the ability of a non programmer to judge programmers. I still hold that the good ones can, and if they cant then how do you propose they pick their technical cofounder? Regarding technical debt, I think we're conflating a few things under this umbrella. There can be code that is easy to read and maintain, but won't scale to millions of users. Then there is spaghetti code which is brittle, hard to read and modify, but may or may not scale. I think it's ok to have the first before you know if you need to scale. When you guys got to the point that you realized it needed to scale was it fixed immediately? If not, would it have been that hard to fix it then. Btw, thank you for talking about this stuff. It's great to hear insights from someone that's been through such things.