6 ms·

I have a degree in computer science, but at the end of the day it's just a piece of paper - I learned programming mainly through the internet. I talked to peopl

I have a degree in computer science, but at the end of the day it's just a piece of paper - I learned programming mainly through the internet. I talked to people who cared enough about programming enough to hang out on IRC, or write technical blog posts, or write their own libraries, etc. What has shocked me since entering the "real world" is how little most other programmers I meet care about programming, their craft, code quality, or learning new things. I was legitimately shocked at how good I was compared to the real world population, as opposed to the "internet programmer" population where I was mediocre at best. This isn't a value judgment - not everyone is passionate about their day job. But it might resonate with someone out there.

SeanDav 10y ago
This agrees with my own experience. I learned programming with people that would do things like write their own graphics library, in Assembly language, or device drivers, just because they wanted to see if they could. I thought every programmer was like that in the professional world - with rare exceptions, they were not.
nickff 10y ago
I agree with everything you say, but would also like to add that the level of passion and 'pride' which programmers have seems to vary by specialization. I work in embedded systems, where having well-factored code, with well thought-out scope is the anomaly, not the rule.
- lacampbell 10y ago
  > I work in embedded systems, where having well-factored code, with well thought-out scope is the anomaly, not the rule. I had always romanticised embedded programming is being the domain of tightly written, well thought out code. I figured there was much less "room for error", so there'd be more scrutiny per functionality. That's been your experience across a few companies?
  - nickff 10y ago
    Embedded software can be very tightly written, with large sections of code written in assembly to save a few instructions, and other portions of code loaded into RAM for faster execution. There are also quite a few programmers who couldn't 'cut it' in web programming, and went over to embedded, where they wreak havoc on small low-cost devices, and another group of programmers who somehow 'fell into' embedded programming many years ago, and have not updated their skills since.
thegeomaster 10y ago
One time, when leaving a company, I helped interview candidates for my old job, since I could best tell what skills are needed and to what extent. I reckoned at the time, from most interactions on the Internet, that I am (globally) a mediocre, if not below-average, developer - in each discussion I participated online, there were always people above my level, from the ones having a slightly better understanding of the subject to the people whose depth of knowledge appeared somewhat otherworldly. This belief was particularly strengthened by the fact that I didn't have much contact with real-world developers in real life, as my friends tended to come from different backgrounds. When the interviews came, I was astonished how many of them couldn't code their way out of a paper bag. The ones who did, wrote code with messed up indentation, inconsistent style, ugly and hackish approaches, and the like. I couldn't imagine how someone could leave their code like that and say "there, this is my finished product." But here they were, and it seemed like they didn't really see anything particularly wrong, or just not important enough to justify the added effort of cleaning the mess up. It was a very strange moment for me. I believe this to be an example of the classical selection bias: people inclined to participate in online discussions, answer questions on StackOverflow, write blogs and type out detailed technical comments on HN are on average a lot more skilled than the average just-earning-my-living developer fresh out of some half-assed "be a software engineer and make tons of money!" three-month course.
- furyofantares 10y ago
  There is another very strong bias that goes on when hiring, though. Take 9 competent developers who tend to get offers and 1 that can't code their way out of a box. That 1 could very easily do more interviews than the other 9 combined before landing a job (and will be back on the market sooner to boot) and interviewers might conclude them typical and the other 9 atypical even though the reverse is true.
- keithnoizu 10y ago
  I make constraint based short term implementation decisions You sometimes resort to short cuts to meet deadlines. They, are hacks who don't know how to code. But yeah I never consider myself to be a great developer until interacting with other developers.
k__ 10y ago
My CS degree didn't teach me how to code, but it helped me with a few background informations. I'm really bad at Math, but CS helped me to understand FP and algorithms a bit more.
realusername 10y ago
I have honestly seen the exact same thing. I was rating myself quite average or just below average. I found actually that as a web developer, if you have a general culture of lower level computing and can produce readable and maintainable code, you are already in the top 10%.
wott 10y ago
Yeah, I don't even have a CS degree. I was considering myself below average as long as I was working mostly alone or on specific domains, for I could not compare with others IRL. I could only read people on Usenet or on the Web and they often looked 10 times as knowledgeable as I was. Also, I could see that other professionals listed impressive job titles and definitions, so I was, yes, really impressed and couldn't see how I could ever match those advertised skills. Then I got a job in a bigger company, where because of the nature of the job, I could easily compare with other people in a large team, in the rest of company, and in other companies; and I quickly noticed I was in the top 10% or perhaps even 5%. That was at the same time very surprising and... very appalling, because that meant that all the big titles of those guys were just kind of fake, empty. it felt a bit as if I had been deceived. Even though they had CS degrees, they had vast holes in basic programming know-how an in computer knowledge, and they didn't give a fuck about it, as little as they cared about doing a clean work. So the people I used to read on Usenet or the Web were indeed exceptions and not the norm, and sometimes pretty much gurus in their domain. Anyway, they were not at all representative of the majority of developers that populate companies.
- GuiA 10y ago
  > I quickly noticed I was in the top 10% or perhaps even 5%. That was at the same time very surprising and... very appalling, because that meant that all the big titles of those guys were just kind of fake, empty. Keep in mind that following that reasoning, people in the top 1% would feel that your title is fake and empty. Would you then say that it's a fair perspective?
  - nitrogen 10y ago
    If that supposed 1%er (all else being equal like negotiating skill, personality, etc.) is making less money or receiving less respect, then yes, that's a fair perspective.
    - ramblerman 10y ago
      shouldn't the 1%er move up rather than criticise the rest down? I mean by definition there are only so many 1%ers to go around to fill up top spots.
kayman 10y ago
When I came out of college, some real life examples of people who do not seem to care at all which shocked me: - CTO of a company I worked for (brother in law of the company director) typed with 2 fingers. No Joke - Senior Software developer to nullify a list, he just creates a "new list" instead of setting it to "null" End result from practical point of view is the same. But the lack of computer science insight baffled me. - Team lead implements lines of code as a tool to measure productivity. Being a new kid out of school, I felt too young to call bullshit but intuitively, I felt the metric was flawed.
- niij 10y ago
  Peck and typer here. I didn't learn to type "correctly" but I can still do my job.
- mikekchar 10y ago
  One thing to keep in mind is that there is a difference between a metric and measure. A measure is basically exactly what it says on the box: it's something that you have measured. A metric is a measure that you use to drive process changes. LOC is a good measure, but a truly terrible metric. The reason it is a terrible metric is because it easily gamed (both consciously and unconsciously). The same functionality can be implemented in 1 line or 100 lines. The amount of time it takes to write 1 line can be more than the amount of time it takes to write 100 lines. You get the point. LOC can, however, be a good measure. You can test this yourself if you like. Go through an old project (something with a year's worth of code). Make a list of all the features that were implemented in that year. Estimate the amount of work for each feature (or use whatever estimates you had before). Make a rolling average of "amount of work" over each week. Now go into your code repository and make a rolling average for the number of lines of code changed each week (so basically just add the lines added to the lines deleted). I think you will find that there is a correlation between the average estimated effort and the average change in LOC every week. This is because over the life of a project, developers tend to use the same kinds of techniques, the same idioms, etc. Occasionally, you will find that the relationship between estimated effort and LOC changes dramatically. In my experience, you will discover that this corresponds with a change in development mentality. Something has happened on the team that changes the way they write code. So it's a good measure for that kind of thing. For example, I once had to deal with political problems from upper management where they were convinced that the programmers were not focusing on their job. I could show them very easily from graphs of estimated effort and lines of code that it was very much business as usual. All this to say that if your team lead is encouraging you to increase your number of lines of code out the door, then it is indeed a flawed metric. But if the team lead is measuring productivity with lines of code, it may very well be a decent measure. You can't use it to affect productivity, but you can use it for other purposes.

SeanDav 10y ago

This agrees with my own experience. I learned programming with people that would do things like write their own graphics library, in Assembly language, or device drivers, just because they wanted to see if they could. I thought every programmer was like that in the professional world - with rare exceptions, they were not.

nickff 10y ago

I agree with everything you say, but would also like to add that the level of passion and 'pride' which programmers have seems to vary by specialization. I work in embedded systems, where having well-factored code, with well thought-out scope is the anomaly, not the rule.

lacampbell 10y ago
> I work in embedded systems, where having well-factored code, with well thought-out scope is the anomaly, not the rule. I had always romanticised embedded programming is being the domain of tightly written, well thought out code. I figured there was much less "room for error", so there'd be more scrutiny per functionality. That's been your experience across a few companies?
- nickff 10y ago
  Embedded software can be very tightly written, with large sections of code written in assembly to save a few instructions, and other portions of code loaded into RAM for faster execution. There are also quite a few programmers who couldn't 'cut it' in web programming, and went over to embedded, where they wreak havoc on small low-cost devices, and another group of programmers who somehow 'fell into' embedded programming many years ago, and have not updated their skills since.

thegeomaster 10y ago

One time, when leaving a company, I helped interview candidates for my old job, since I could best tell what skills are needed and to what extent. I reckoned at the time, from most interactions on the Internet, that I am (globally) a mediocre, if not below-average, developer - in each discussion I participated online, there were always people above my level, from the ones having a slightly better understanding of the subject to the people whose depth of knowledge appeared somewhat otherworldly. This belief was particularly strengthened by the fact that I didn't have much contact with real-world developers in real life, as my friends tended to come from different backgrounds. When the interviews came, I was astonished how many of them couldn't code their way out of a paper bag. The ones who did, wrote code with messed up indentation, inconsistent style, ugly and hackish approaches, and the like. I couldn't imagine how someone could leave their code like that and say "there, this is my finished product." But here they were, and it seemed like they didn't really see anything particularly wrong, or just not important enough to justify the added effort of cleaning the mess up. It was a very strange moment for me. I believe this to be an example of the classical selection bias: people inclined to participate in online discussions, answer questions on StackOverflow, write blogs and type out detailed technical comments on HN are on average a lot more skilled than the average just-earning-my-living developer fresh out of some half-assed "be a software engineer and make tons of money!" three-month course.

furyofantares 10y ago
There is another very strong bias that goes on when hiring, though. Take 9 competent developers who tend to get offers and 1 that can't code their way out of a box. That 1 could very easily do more interviews than the other 9 combined before landing a job (and will be back on the market sooner to boot) and interviewers might conclude them typical and the other 9 atypical even though the reverse is true.
keithnoizu 10y ago
I make constraint based short term implementation decisions You sometimes resort to short cuts to meet deadlines. They, are hacks who don't know how to code. But yeah I never consider myself to be a great developer until interacting with other developers.

k__ 10y ago

My CS degree didn't teach me how to code, but it helped me with a few background informations. I'm really bad at Math, but CS helped me to understand FP and algorithms a bit more.

realusername 10y ago

I have honestly seen the exact same thing. I was rating myself quite average or just below average. I found actually that as a web developer, if you have a general culture of lower level computing and can produce readable and maintainable code, you are already in the top 10%.

wott 10y ago

Yeah, I don't even have a CS degree. I was considering myself below average as long as I was working mostly alone or on specific domains, for I could not compare with others IRL. I could only read people on Usenet or on the Web and they often looked 10 times as knowledgeable as I was. Also, I could see that other professionals listed impressive job titles and definitions, so I was, yes, really impressed and couldn't see how I could ever match those advertised skills. Then I got a job in a bigger company, where because of the nature of the job, I could easily compare with other people in a large team, in the rest of company, and in other companies; and I quickly noticed I was in the top 10% or perhaps even 5%. That was at the same time very surprising and... very appalling, because that meant that all the big titles of those guys were just kind of fake, empty. it felt a bit as if I had been deceived. Even though they had CS degrees, they had vast holes in basic programming know-how an in computer knowledge, and they didn't give a fuck about it, as little as they cared about doing a clean work. So the people I used to read on Usenet or the Web were indeed exceptions and not the norm, and sometimes pretty much gurus in their domain. Anyway, they were not at all representative of the majority of developers that populate companies.

GuiA 10y ago
> I quickly noticed I was in the top 10% or perhaps even 5%. That was at the same time very surprising and... very appalling, because that meant that all the big titles of those guys were just kind of fake, empty. Keep in mind that following that reasoning, people in the top 1% would feel that your title is fake and empty. Would you then say that it's a fair perspective?
- nitrogen 10y ago
  If that supposed 1%er (all else being equal like negotiating skill, personality, etc.) is making less money or receiving less respect, then yes, that's a fair perspective.
  - ramblerman 10y ago
    shouldn't the 1%er move up rather than criticise the rest down? I mean by definition there are only so many 1%ers to go around to fill up top spots.

kayman 10y ago

When I came out of college, some real life examples of people who do not seem to care at all which shocked me: - CTO of a company I worked for (brother in law of the company director) typed with 2 fingers. No Joke - Senior Software developer to nullify a list, he just creates a "new list" instead of setting it to "null" End result from practical point of view is the same. But the lack of computer science insight baffled me. - Team lead implements lines of code as a tool to measure productivity. Being a new kid out of school, I felt too young to call bullshit but intuitively, I felt the metric was flawed.

niij 10y ago
Peck and typer here. I didn't learn to type "correctly" but I can still do my job.
mikekchar 10y ago
One thing to keep in mind is that there is a difference between a metric and measure. A measure is basically exactly what it says on the box: it's something that you have measured. A metric is a measure that you use to drive process changes. LOC is a good measure, but a truly terrible metric. The reason it is a terrible metric is because it easily gamed (both consciously and unconsciously). The same functionality can be implemented in 1 line or 100 lines. The amount of time it takes to write 1 line can be more than the amount of time it takes to write 100 lines. You get the point. LOC can, however, be a good measure. You can test this yourself if you like. Go through an old project (something with a year's worth of code). Make a list of all the features that were implemented in that year. Estimate the amount of work for each feature (or use whatever estimates you had before). Make a rolling average of "amount of work" over each week. Now go into your code repository and make a rolling average for the number of lines of code changed each week (so basically just add the lines added to the lines deleted). I think you will find that there is a correlation between the average estimated effort and the average change in LOC every week. This is because over the life of a project, developers tend to use the same kinds of techniques, the same idioms, etc. Occasionally, you will find that the relationship between estimated effort and LOC changes dramatically. In my experience, you will discover that this corresponds with a change in development mentality. Something has happened on the team that changes the way they write code. So it's a good measure for that kind of thing. For example, I once had to deal with political problems from upper management where they were convinced that the programmers were not focusing on their job. I could show them very easily from graphs of estimated effort and lines of code that it was very much business as usual. All this to say that if your team lead is encouraging you to increase your number of lines of code out the door, then it is indeed a flawed metric. But if the team lead is measuring productivity with lines of code, it may very well be a decent measure. You can't use it to affect productivity, but you can use it for other purposes.