6 ms·

Never judge a programmer by their commit history

59 points by MehdiKhalili 13y ago

fmdud 13y ago
I think this could be shortened to 'Never judge a programmer'. Seriously though, outside of an interview environment or training, why are we trying to assess people's capabilities anyway? This kind of penis-measuring contest is so prevalent in our industry; it makes people incredibly afraid of actually putting themselves out there and helping to create. Judging other people is a bad trait. Simple as that.
- samspot 13y ago
  So if people are continuously creating unmaintainable messes and technical debt we should just throw up our hands and say "oh well, we shouldn't judge"? Assessing capabilities is required for improvement. If someone is creating poor quality work we can either replace them or train them to do better. But if we can't assess them then we won't know when to do either one.
  - collyw 13y ago
    I am coming to the conclusion now that actually talking to a programmer is the best way to judge. I have had various interviews in the last couple of years. One I got offered the job without so much as any technical test, based on my CV. I almost felt a bit cheated there, as I wanted to prove I was good. I interviewed for a startup with non technical founders. They had pulled a Python test from the internet which seemed 90% about lambdas in Python (I can use them, but in most cases list comprehensions provide a more readable syntax). I actually like being able to explain my thought process in an interview. Even if I don't get it right, then they may see that I am "almost there". Likewise if I don't know something, I can tell them. I have a fair idea about my colleges work, not from their code, but by the way they talk about it, and seeing the tools they use. (The "best" in my office of 4 chooses Java for most of his stuff for some reason - not what I would expect from someone good. The worst code was written by someone who ranted about how I should be choosing Python over Perl.)
- wreegab 13y ago
  Judging code is fine though, isn't?
- Pacabel 13y ago
  We need to assess people's capabilities so we can try to allocate our resources as best as we can, especially when facing changing circumstances and limited budgets. When assigning work, I need to know if one programmer is likely better than another at a given task. If Dave tends to work more efficiently with C++ than Gupta does, I'm going to give the C++ work to Dave. If Gupta tends to work more efficiently with Visual Basic than Dave does, then I'm going to have Gupta maintain the old Visual Basic apps. This is business. We're here to allocate our resources, be they money or people, as best as we can in order to get the greatest return. Professional programmers will set aside their emotions in order to achieve this goal, and will accept being judged as part of the resource allocation process. They realize that this isn't some fantasy where everybody is happy all of the time, and nobody's feelings get hurt.
  - pekk 13y ago
    It is equally an impossible idealization to think that people usually do set aside their emotions, and only make "technical" criticisms objectively. The phrase "resource allocation" should have tipped us off to how fast and hard this becomes Machiavellian. If one programmer kisses up much better, went to the right school, or is of a preferred race or political party, or successfully claims the work of the other, etc. - the boss will mysteriously find that this one is more competent. Since the rationale that we decide everything by merit is unassailable and taken for granted, we bias merit judgments to suit our goals. Any objection can be met by accusing the objector of being emotional and wanting to compromise the merit-based system. In reality merit is determined by a political process. Every single HN poster will, by amazing chance, turn out to be a shining exception to this rule, completely unbiased by personal opinion or politics.
  - collyw 13y ago
    I could see a problem with your methodology where someone is "good with excel", gets to clean up all the shit execl problems, never gets to work on anything interesting, never gets to improve, or learn the C++, which he may be better at given 6 months of using it.
    - Pacabel 13y ago
deleted 13y ago
[deleted]
- acangiano 13y ago
  Mehdi Khalili.
namenotrequired 13y ago
Good post but why is your name in the title?
- jasonlotito 13y ago
  Most likely it's because the script being used to submit this auto-included the pages title, which includes his name. Considering that the official HN submit script† does this, it's an honest mistake. † http://ycombinator.com/bookmarklet.html http://ycombinator.com/bookmarklet.html
  - MehdiKhalili 13y ago
    It's AddThis. Fixed. Thanks guys.
    - skrebbel 13y ago
      Sorry for being an asshole about it. I deleted my comment.
      - MehdiKhalili 13y ago
        Not at all. The post was published by AddThis and I didn't realize the issue. I am glad it was highlighted so I could fix it sooner than later. Thanks.
    - namenotrequired 13y ago
      Thank you!
NateDad 13y ago
If I can't judge you by your code, how should I judge you? Now, that's not to say that I shouldn't take other things into consideration, like your experience at the time. Obviously I'd never expect a junior dev's code to look like someone with 10 years experience. And yes, if you're working at a place with terrible coding standards, and for some reason I have access to that code (most of the time those places aren't producing open source code), you can explain why everything is static public or whatever. That's fine. It's not like you can't still write good code that is static public... show me how you write code that is still clear and concise and isolated etc etc even within the restrictions of the coding standards. Definitely, you can and should tack on some personal information about the circumstances around the code you show to people. I have stuff in github that is half-baked. No big deal. Instead, I say "here, this is an example of my work that I consider to be high quality, and is an example of the code I would write for you if given the chance. That other repo is just some stuff I was messing around with, and I never fully put in the time to make it correct, because it was just a proof of concept." And as for personal issues.... sorry, but this is life, and you might have those when you're working for my company. And I need you to be able to at least do an acceptable job regardless. I'm hiring a coder. I'm going to look at your code. Just like if I'm hiring a cabinet maker, I'm going to look at his cabinets. If he says "sorry I was tired that week" and shows me crappy cabinets, I'm going to worry that he might be tired on the week he builds my cabinets.
- einhverfr 13y ago
  > If I can't judge you by your code, how should I judge you? I judge a programmer by the contributions he or she has made to various open source projects. Now that sounds like judging by code, right? Well only partly. Other things that matter is how many projects someone has committed to, what the people of the project teams say, etc. The thing is I can't know the context looking at the code. What I can do is look at how successful the open source projects are and what their co-committers have to say. Now, usually the co-committers will say something positive, but what they say is important.
  - collyw 13y ago
    So how would you judge someone like me who has no open source projects? Work stuff is in house, and I don't have the time outside of work to contribute anything meaningful.
rartichoke 13y ago
It's definitely true. People don't really understand the circumstances the coder was in when writing the code. I sometimes come across low paying clients who try to take advantage of you at every chance. They also come to me with hosting and have even changed hosts without even asking me while having no tech knowledge (then call me to fix the million errors they have). For these clients I usually just throw together some fast low quality hand rolled PHP sites if they are not very demanding sites. There won't be tests, I'll haphazardly inline some CSS because when you get paid almost nothing the last thing you're thinking about is wonderful to work with abstractions that are maintainable. You're only thinking about getting the job done as fast as possible and getting out because you have no interest in doing business with them again and due to their personality you don't want to be recommended to their friends. If you compare that code to the code I write for my own side projects or proper clients it's night and day. You wouldn't even know they are the same person.
- nailer 13y ago
  I contributed a fix to something on github, making one function signature which required 'options' have them optional like all the other functions. Repeated throughout the code base was some copypasta. I dutifully committed more copypasta.
  - rartichoke 13y ago
    Yeah, that reminds me of the broken window tip from the pragmatic programmer book.
- erikb 13y ago
  Applying Pareto's rule to your client list might help improve your life's happiness and hourly rate tremendously. Saying that you need to do bad work because your clients don't pay you well enough is a quite bad excuse.
  - rartichoke 13y ago
    It's not as simple as you think it is. A lot of them already use shared hosting from previous sites and want to stay with them because it happens to work in their case. So now you're stuck using some old version of PHP and mysql. What if you haven't bothered spending a ton of time with PHP lately and for the last few years you've been working with node and rails on projects you deem "worthy"? Should I spend dozens of hours researching best practices for an obsolete version of PHP and make sure I do it right? Or should I lecture someone on reasons why they should allow me to host their site somewhere else and then setup a VPS for them? No frikken way. Also when you need money, you accept work. That is how the world works. For some people/situations it's not worth throwing away $400 on some job because of annoying clients. You deal with it and put the money in your bank.
wreegab 13y ago
It's nice when acronyms, such as "TDD" and "BDD" here, are expanded at least once in the text when they first occur -- I don't think it would put a lot of burden on writers. There is too much of these insider knowledge acronyms all over the internet nowadays. Anyways... I gather "TDD" means "Test-Driven Development" and "BDD" means "Behavior-Driven Development".
- collyw 13y ago
  What the hell is behaviour driven development? Everyone has some sort of behaviour, so it sounds as if everyone must be practising it. Recently I spotted a new one, domain driven development. I decided to read up on it and realised this is how I had been taught to design code, and how I generally go about doing things. Its got a name now.
  - MehdiKhalili 13y ago
    I have explained Behavior Driven Development and its benefits here http://www.mehdi-khalili.com/bdd-to-the-rescue http://www.mehdi-khalili.com/bdd-to-the-rescue. Hope it helps.
    - collyw 13y ago
      Thanks for that but to be honest it just sound like more of the same, but viewed from a different angle. My understanding of your write up is that that tests may be written without understanding the problem. I mean that is just dumb TDD religious zealots who would do that sort of thing, assuming that test make up for design (and thought process). I also think that the verification process is an inherent part of waterfall model - hence the iterations.
  - nailer 13y ago
    Test driven development with silly/vague method names, like it() and should(), often written by people who don't write the code so behaviour can be defined separately from implementation. It was quite popular in the ruby community a couple of years ago.
- 13y ago
a3voices 13y ago
He missed the biggest reason, which is that projects are often coded quickly to just "get it working" in a fast time frame.
- collyw 13y ago
  yep. I look back at some bits of my own code and realise they are a mess. If it needs changed anyway, and I have time, I'll use the "fresh look" at my code to decide what is wrong with it, and what could be better. Refactor from there. Another one would be constantly changing requirements. So you start with something nice. Add a quick hack to do a little more. Rinse, repeat, until it becomes an unmaintainable mess.
- MehdiKhalili 13y ago
  That was in the MVP (minimum viable product) section. I also referred to an old post of mine, on bad code http://www.mehdi-khalili.com/bad-code http://www.mehdi-khalili.com/bad-code, where I explain that in great details. I hope you find that useful.
tokenrove 13y ago
The situation is slightly more complex: Programmers write bad code for many different reasons, but good code only gets written by good programmers. So I think it's fine to judge someone on their commit history, as long as one is understanding of the bad code that inevitably happens. The good code doesn't happen by accident.
- gress 13y ago
  I wish I could upvote this more. I guess a corollary would be that if there is some good code in a programmer's history, we can ask "what circumstances made this possible?" and learn how to get the best out of people, rather than looking to find the worst in them.
whyme 13y ago
So we've gone from "Don't judge a book by its' cover" to 'Don't judge a book by its' content'? How about don't judge anyone until having "walked a mile in their shoes"? Or even... "Don't judge". Ideally, "before you judge...", you at least spend some time getting to know the person to find out a little more about who it is you're judging. And maybe that's really the issue. http://www.goodreads.com/quotes/tag/judge http://www.goodreads.com/quotes/tag/judge
- MehdiKhalili 13y ago
  Couldn't agree more
- erikb 13y ago
  Guessing applicant quality based on evaluating the information you have about him is not judging. I can say "this guy is not a good match for our team, philosophy, and/or strategy" without saying "he is worthless"!
  - deleted 13y ago
    [deleted]
  - whyme 13y ago
    Guessing applicant quality is making a judgment of their capability, which is the core point of the article. I never suggested anyone was judging solely on a persons worth. I am suggesting that getting to know the person provides better insight in all regards. Edit: And quite frankly hiring a programmer solely on programming capability can often lead to disastrous consequences. So if you can see some higher quality examples, it's worth investigating - IMHO.
    - deleted 13y ago
      [deleted]
hanswesterbeek 13y ago
Agree with the blog. Context is (almost) everything.
Wheen 13y ago
As someone who is (Probably a bit more than) a junior dev with no formal education or experience in a team, do you have any suggestions to write better code? I feel like my code would be considered bad, but I have no idea what good or bad code looks like. Does anyone have some examples and comparisons between good and bad code?
- sparkie 13y ago
  Really depends on the language and paradigm you're using, but the general aim for writing good code is to aim for loose coupling, high cohesion, don't repeat yourself, the single responsibility principle, and the Open/Closed principle (and several other philosophies) in order to maximize code re-usability and reduce maintenance effort. You should aim to use whatever features your language provides to attempt to enforce the above, by information hiding, encapsulation, avoiding global mutable state as much as possible, and using design patterns to achieve a good balance. You could give two similarly experienced programmers a fairly trivial problem and they might come up with wildly different solutions, because the best solution is a myth, but we know the wrong solution if we see it (that comes from the experience of making the same mistakes.) If you give details on the language(s) you're using I may be able to point you to some literature on good design.
  - Wheen 13y ago
    Sorry for the late reply. Recently, mostly Python and Javascript

59 points by MehdiKhalili 13y ago

fmdud 13y ago

I think this could be shortened to 'Never judge a programmer'. Seriously though, outside of an interview environment or training, why are we trying to assess people's capabilities anyway? This kind of penis-measuring contest is so prevalent in our industry; it makes people incredibly afraid of actually putting themselves out there and helping to create. Judging other people is a bad trait. Simple as that.

samspot 13y ago
So if people are continuously creating unmaintainable messes and technical debt we should just throw up our hands and say "oh well, we shouldn't judge"? Assessing capabilities is required for improvement. If someone is creating poor quality work we can either replace them or train them to do better. But if we can't assess them then we won't know when to do either one.
- collyw 13y ago
  I am coming to the conclusion now that actually talking to a programmer is the best way to judge. I have had various interviews in the last couple of years. One I got offered the job without so much as any technical test, based on my CV. I almost felt a bit cheated there, as I wanted to prove I was good. I interviewed for a startup with non technical founders. They had pulled a Python test from the internet which seemed 90% about lambdas in Python (I can use them, but in most cases list comprehensions provide a more readable syntax). I actually like being able to explain my thought process in an interview. Even if I don't get it right, then they may see that I am "almost there". Likewise if I don't know something, I can tell them. I have a fair idea about my colleges work, not from their code, but by the way they talk about it, and seeing the tools they use. (The "best" in my office of 4 chooses Java for most of his stuff for some reason - not what I would expect from someone good. The worst code was written by someone who ranted about how I should be choosing Python over Perl.)
wreegab 13y ago
Judging code is fine though, isn't?
Pacabel 13y ago
We need to assess people's capabilities so we can try to allocate our resources as best as we can, especially when facing changing circumstances and limited budgets. When assigning work, I need to know if one programmer is likely better than another at a given task. If Dave tends to work more efficiently with C++ than Gupta does, I'm going to give the C++ work to Dave. If Gupta tends to work more efficiently with Visual Basic than Dave does, then I'm going to have Gupta maintain the old Visual Basic apps. This is business. We're here to allocate our resources, be they money or people, as best as we can in order to get the greatest return. Professional programmers will set aside their emotions in order to achieve this goal, and will accept being judged as part of the resource allocation process. They realize that this isn't some fantasy where everybody is happy all of the time, and nobody's feelings get hurt.
- pekk 13y ago
  It is equally an impossible idealization to think that people usually do set aside their emotions, and only make "technical" criticisms objectively. The phrase "resource allocation" should have tipped us off to how fast and hard this becomes Machiavellian. If one programmer kisses up much better, went to the right school, or is of a preferred race or political party, or successfully claims the work of the other, etc. - the boss will mysteriously find that this one is more competent. Since the rationale that we decide everything by merit is unassailable and taken for granted, we bias merit judgments to suit our goals. Any objection can be met by accusing the objector of being emotional and wanting to compromise the merit-based system. In reality merit is determined by a political process. Every single HN poster will, by amazing chance, turn out to be a shining exception to this rule, completely unbiased by personal opinion or politics.
- collyw 13y ago
  I could see a problem with your methodology where someone is "good with excel", gets to clean up all the shit execl problems, never gets to work on anything interesting, never gets to improve, or learn the C++, which he may be better at given 6 months of using it.
  - Pacabel 13y ago

deleted 13y ago

[deleted]

acangiano 13y ago
Mehdi Khalili.

namenotrequired 13y ago

Good post but why is your name in the title?

jasonlotito 13y ago
Most likely it's because the script being used to submit this auto-included the pages title, which includes his name. Considering that the official HN submit script† does this, it's an honest mistake. † http://ycombinator.com/bookmarklet.html http://ycombinator.com/bookmarklet.html
- MehdiKhalili 13y ago
  It's AddThis. Fixed. Thanks guys.
  - skrebbel 13y ago
    Sorry for being an asshole about it. I deleted my comment.
    - MehdiKhalili 13y ago
      Not at all. The post was published by AddThis and I didn't realize the issue. I am glad it was highlighted so I could fix it sooner than later. Thanks.
  - namenotrequired 13y ago
    Thank you!

NateDad 13y ago

If I can't judge you by your code, how should I judge you? Now, that's not to say that I shouldn't take other things into consideration, like your experience at the time. Obviously I'd never expect a junior dev's code to look like someone with 10 years experience. And yes, if you're working at a place with terrible coding standards, and for some reason I have access to that code (most of the time those places aren't producing open source code), you can explain why everything is static public or whatever. That's fine. It's not like you can't still write good code that is static public... show me how you write code that is still clear and concise and isolated etc etc even within the restrictions of the coding standards. Definitely, you can and should tack on some personal information about the circumstances around the code you show to people. I have stuff in github that is half-baked. No big deal. Instead, I say "here, this is an example of my work that I consider to be high quality, and is an example of the code I would write for you if given the chance. That other repo is just some stuff I was messing around with, and I never fully put in the time to make it correct, because it was just a proof of concept." And as for personal issues.... sorry, but this is life, and you might have those when you're working for my company. And I need you to be able to at least do an acceptable job regardless. I'm hiring a coder. I'm going to look at your code. Just like if I'm hiring a cabinet maker, I'm going to look at his cabinets. If he says "sorry I was tired that week" and shows me crappy cabinets, I'm going to worry that he might be tired on the week he builds my cabinets.

einhverfr 13y ago
> If I can't judge you by your code, how should I judge you? I judge a programmer by the contributions he or she has made to various open source projects. Now that sounds like judging by code, right? Well only partly. Other things that matter is how many projects someone has committed to, what the people of the project teams say, etc. The thing is I can't know the context looking at the code. What I can do is look at how successful the open source projects are and what their co-committers have to say. Now, usually the co-committers will say something positive, but what they say is important.
- collyw 13y ago
  So how would you judge someone like me who has no open source projects? Work stuff is in house, and I don't have the time outside of work to contribute anything meaningful.

rartichoke 13y ago

It's definitely true. People don't really understand the circumstances the coder was in when writing the code. I sometimes come across low paying clients who try to take advantage of you at every chance. They also come to me with hosting and have even changed hosts without even asking me while having no tech knowledge (then call me to fix the million errors they have). For these clients I usually just throw together some fast low quality hand rolled PHP sites if they are not very demanding sites. There won't be tests, I'll haphazardly inline some CSS because when you get paid almost nothing the last thing you're thinking about is wonderful to work with abstractions that are maintainable. You're only thinking about getting the job done as fast as possible and getting out because you have no interest in doing business with them again and due to their personality you don't want to be recommended to their friends. If you compare that code to the code I write for my own side projects or proper clients it's night and day. You wouldn't even know they are the same person.

nailer 13y ago
I contributed a fix to something on github, making one function signature which required 'options' have them optional like all the other functions. Repeated throughout the code base was some copypasta. I dutifully committed more copypasta.
- rartichoke 13y ago
  Yeah, that reminds me of the broken window tip from the pragmatic programmer book.
erikb 13y ago
Applying Pareto's rule to your client list might help improve your life's happiness and hourly rate tremendously. Saying that you need to do bad work because your clients don't pay you well enough is a quite bad excuse.
- rartichoke 13y ago
  It's not as simple as you think it is. A lot of them already use shared hosting from previous sites and want to stay with them because it happens to work in their case. So now you're stuck using some old version of PHP and mysql. What if you haven't bothered spending a ton of time with PHP lately and for the last few years you've been working with node and rails on projects you deem "worthy"? Should I spend dozens of hours researching best practices for an obsolete version of PHP and make sure I do it right? Or should I lecture someone on reasons why they should allow me to host their site somewhere else and then setup a VPS for them? No frikken way. Also when you need money, you accept work. That is how the world works. For some people/situations it's not worth throwing away $400 on some job because of annoying clients. You deal with it and put the money in your bank.

wreegab 13y ago

It's nice when acronyms, such as "TDD" and "BDD" here, are expanded at least once in the text when they first occur -- I don't think it would put a lot of burden on writers. There is too much of these insider knowledge acronyms all over the internet nowadays. Anyways... I gather "TDD" means "Test-Driven Development" and "BDD" means "Behavior-Driven Development".

collyw 13y ago
What the hell is behaviour driven development? Everyone has some sort of behaviour, so it sounds as if everyone must be practising it. Recently I spotted a new one, domain driven development. I decided to read up on it and realised this is how I had been taught to design code, and how I generally go about doing things. Its got a name now.
- MehdiKhalili 13y ago
  I have explained Behavior Driven Development and its benefits here http://www.mehdi-khalili.com/bdd-to-the-rescue http://www.mehdi-khalili.com/bdd-to-the-rescue. Hope it helps.
  - collyw 13y ago
    Thanks for that but to be honest it just sound like more of the same, but viewed from a different angle. My understanding of your write up is that that tests may be written without understanding the problem. I mean that is just dumb TDD religious zealots who would do that sort of thing, assuming that test make up for design (and thought process). I also think that the verification process is an inherent part of waterfall model - hence the iterations.
- nailer 13y ago
  Test driven development with silly/vague method names, like it() and should(), often written by people who don't write the code so behaviour can be defined separately from implementation. It was quite popular in the ruby community a couple of years ago.
13y ago

a3voices 13y ago

He missed the biggest reason, which is that projects are often coded quickly to just "get it working" in a fast time frame.

collyw 13y ago
yep. I look back at some bits of my own code and realise they are a mess. If it needs changed anyway, and I have time, I'll use the "fresh look" at my code to decide what is wrong with it, and what could be better. Refactor from there. Another one would be constantly changing requirements. So you start with something nice. Add a quick hack to do a little more. Rinse, repeat, until it becomes an unmaintainable mess.
MehdiKhalili 13y ago
That was in the MVP (minimum viable product) section. I also referred to an old post of mine, on bad code http://www.mehdi-khalili.com/bad-code http://www.mehdi-khalili.com/bad-code, where I explain that in great details. I hope you find that useful.

tokenrove 13y ago

The situation is slightly more complex: Programmers write bad code for many different reasons, but good code only gets written by good programmers. So I think it's fine to judge someone on their commit history, as long as one is understanding of the bad code that inevitably happens. The good code doesn't happen by accident.

gress 13y ago
I wish I could upvote this more. I guess a corollary would be that if there is some good code in a programmer's history, we can ask "what circumstances made this possible?" and learn how to get the best out of people, rather than looking to find the worst in them.

whyme 13y ago

So we've gone from "Don't judge a book by its' cover" to 'Don't judge a book by its' content'? How about don't judge anyone until having "walked a mile in their shoes"? Or even... "Don't judge". Ideally, "before you judge...", you at least spend some time getting to know the person to find out a little more about who it is you're judging. And maybe that's really the issue. http://www.goodreads.com/quotes/tag/judge http://www.goodreads.com/quotes/tag/judge

MehdiKhalili 13y ago
Couldn't agree more
erikb 13y ago
Guessing applicant quality based on evaluating the information you have about him is not judging. I can say "this guy is not a good match for our team, philosophy, and/or strategy" without saying "he is worthless"!
- deleted 13y ago
  [deleted]
- whyme 13y ago
  Guessing applicant quality is making a judgment of their capability, which is the core point of the article. I never suggested anyone was judging solely on a persons worth. I am suggesting that getting to know the person provides better insight in all regards. Edit: And quite frankly hiring a programmer solely on programming capability can often lead to disastrous consequences. So if you can see some higher quality examples, it's worth investigating - IMHO.
  - deleted 13y ago
    [deleted]

hanswesterbeek 13y ago

Agree with the blog. Context is (almost) everything.

Wheen 13y ago

As someone who is (Probably a bit more than) a junior dev with no formal education or experience in a team, do you have any suggestions to write better code? I feel like my code would be considered bad, but I have no idea what good or bad code looks like. Does anyone have some examples and comparisons between good and bad code?

sparkie 13y ago
Really depends on the language and paradigm you're using, but the general aim for writing good code is to aim for loose coupling, high cohesion, don't repeat yourself, the single responsibility principle, and the Open/Closed principle (and several other philosophies) in order to maximize code re-usability and reduce maintenance effort. You should aim to use whatever features your language provides to attempt to enforce the above, by information hiding, encapsulation, avoiding global mutable state as much as possible, and using design patterns to achieve a good balance. You could give two similarly experienced programmers a fairly trivial problem and they might come up with wildly different solutions, because the best solution is a myth, but we know the wrong solution if we see it (that comes from the experience of making the same mistakes.) If you give details on the language(s) you're using I may be able to point you to some literature on good design.
- Wheen 13y ago
  Sorry for the late reply. Recently, mostly Python and Javascript