3 ms·

So where is the line (for you) between not following a pet programming philosophy and incompetence? If they don't use a bug tracker? If they don't use version

So where is the line (for you) between not following a pet programming philosophy and incompetence? If they don't use a bug tracker? If they don't use version control? If they edit the code on the live servers to make changes/add features? (I've seen all these things) I agree it depends a little on the specific project but a lot of these kinds of best practice stuff are more than just pet programming philosophies. If you are used to or function best in a place with a certain level of professionalism than working somewhere with some cowboys who just wing it or somewhere were the every piece of work is in a feature branch with a corresponding user story, conforms to a style guide and has proper tests is probably not a good fit. Where a team falls on this spectrum is part of the company culture.

deleted 14y ago
[deleted]
mkopinsky 14y ago
When I started at my current job 9 months ago (with me, there are now two programmers in the team), there was no bug tracker or formal version control. We still regularly edit the code on live servers for some bug fixes. The first two were (barely) workable for a one person team and got fixed once the team grew, and the third is honestly the right approach for the kind of software we write. The user base for most of our products numbers in the dozens, and I'd rather get a prod bug fix out there as soon as possible rather than having to mess with commit;cd $prod_dir;pull -u or having to deal with the complexity of having too many code environments. I have not yet succeeded at getting a proper testing framework in place - too much hassle dealing with selenium and we don't yet have enough tests written to justify spending more effort. It's the initial capital investment that'll make it worth it, but I just haven't gotten around to it. Rather work on building an actual product that'll add direct value rather than just saving my ass. These are all practices that in a larger team, or with a larger user base, or with higher requirements, would be untenable. But they work for us, for now.
- freshhawk 14y ago
  I've certainly been in that same situation and made the same choices (version control/bug tracker a must, tests would be great but no one finds the time and once it's been left a while then it never gets done). It was a defensible choice at the time. I learned my lesson though, retroactively adding proper deployment practices is pretty easy, adding tests later is freaking impossible. It's harder to do later when the code isn't fresh in your head (or you didn't even write it) and it takes a lot of time to write tests for legacy code and getting approval to take that much time away is near impossible. Now I pay the 5% tax to do things right and develop features 2-3 times faster long term. (Those numbers are based on pulling some numbers from my work logs and time sheets a while ago, they are very rough and small sample size on a project where there was legacy code with no tests and new code with tests). To go back to my point though, it's not some rabid devotion to some pet philosophy that would make me think seriously about starting a new job somewhere where they don't test. It's because I've done both and I like my job so much more when I don't have to deal with the bullshit that comes from years or even just months of developer laziness (often my laziness). I can spend more time concentrating on creative problem solving and actual features and less on debugging fragile code.
  - mkopinsky 14y ago
    At this point, I'm not convinced that not testing necessarily leads to laziness. In my job I deal with a fair amount of legacy code, and definitely find anecdotally that I work several times faster on new code, but that's because the legacy code is crap and the new code is clean and brilliant (just like all code written by yours truly). (Of course, the fact that the code is new and is being edited by the original author are the primary drivers, but I think my code quality is slightly better than my predecessors'.) Once the code is well-written, I don't think that adding tests would significantly improve my productivity. Having a test suite would give me confidence and save me time doing manual testing (no need to test features I haven't touched and am not worried about), but don't see it having a major impact on my development productivity per se.
    - freshhawk 14y ago
      I meant that laziness leads to not testing. And the "bullshit' that arises from not testing are the bugs and regressions that happen after you role out anything new that isn't completely self contained. "Once the code is well-written, I don't think that adding tests would significantly improve my productivity" Yeah, if you never touch that code again then it would not, I agree. I don't have many modules or classes that never change though. I suppose there might be other types of programming where that's not the case.

deleted 14y ago

[deleted]

mkopinsky 14y ago

When I started at my current job 9 months ago (with me, there are now two programmers in the team), there was no bug tracker or formal version control. We still regularly edit the code on live servers for some bug fixes. The first two were (barely) workable for a one person team and got fixed once the team grew, and the third is honestly the right approach for the kind of software we write. The user base for most of our products numbers in the dozens, and I'd rather get a prod bug fix out there as soon as possible rather than having to mess with commit;cd $prod_dir;pull -u or having to deal with the complexity of having too many code environments. I have not yet succeeded at getting a proper testing framework in place - too much hassle dealing with selenium and we don't yet have enough tests written to justify spending more effort. It's the initial capital investment that'll make it worth it, but I just haven't gotten around to it. Rather work on building an actual product that'll add direct value rather than just saving my ass. These are all practices that in a larger team, or with a larger user base, or with higher requirements, would be untenable. But they work for us, for now.

freshhawk 14y ago
I've certainly been in that same situation and made the same choices (version control/bug tracker a must, tests would be great but no one finds the time and once it's been left a while then it never gets done). It was a defensible choice at the time. I learned my lesson though, retroactively adding proper deployment practices is pretty easy, adding tests later is freaking impossible. It's harder to do later when the code isn't fresh in your head (or you didn't even write it) and it takes a lot of time to write tests for legacy code and getting approval to take that much time away is near impossible. Now I pay the 5% tax to do things right and develop features 2-3 times faster long term. (Those numbers are based on pulling some numbers from my work logs and time sheets a while ago, they are very rough and small sample size on a project where there was legacy code with no tests and new code with tests). To go back to my point though, it's not some rabid devotion to some pet philosophy that would make me think seriously about starting a new job somewhere where they don't test. It's because I've done both and I like my job so much more when I don't have to deal with the bullshit that comes from years or even just months of developer laziness (often my laziness). I can spend more time concentrating on creative problem solving and actual features and less on debugging fragile code.
- mkopinsky 14y ago
  At this point, I'm not convinced that not testing necessarily leads to laziness. In my job I deal with a fair amount of legacy code, and definitely find anecdotally that I work several times faster on new code, but that's because the legacy code is crap and the new code is clean and brilliant (just like all code written by yours truly). (Of course, the fact that the code is new and is being edited by the original author are the primary drivers, but I think my code quality is slightly better than my predecessors'.) Once the code is well-written, I don't think that adding tests would significantly improve my productivity. Having a test suite would give me confidence and save me time doing manual testing (no need to test features I haven't touched and am not worried about), but don't see it having a major impact on my development productivity per se.
  - freshhawk 14y ago
    I meant that laziness leads to not testing. And the "bullshit' that arises from not testing are the bugs and regressions that happen after you role out anything new that isn't completely self contained. "Once the code is well-written, I don't think that adding tests would significantly improve my productivity" Yeah, if you never touch that code again then it would not, I agree. I don't have many modules or classes that never change though. I suppose there might be other types of programming where that's not the case.