12 ms·

> So many things have to go right just to get a software program to compile. That’s why attention to detail is so important... Even the sloppiest coders who wo

by asaph 8y ago

> So many things have to go right just to get a software program to compile. That’s why attention to detail is so important... Even the sloppiest coders who work with no attention to detail still compile their code with ease. I get the author's larger point about attention to detail but I don't think compilation is an effective example to illustrate that point.

bmj 8y ago
Agreed. I generally see a lack of attention to detail with regard to things like linting, unit tests, and documentation. Our CI builds fail way too often due to the first two items, which can be easily done via a single build target on a developer's machine.
- asaph 8y ago
  A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures.
  - swsieber 8y ago
    And you can generally set that hook up to be installed automatically through whatever build tool runs your stuff, like gradle for java stuff, or yarn/npm for js/ts stuff. And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason. Attention to detail in developer tooling can reduce the amount of details developers have to pay attention to.
    - SketchySeaBeast 8y ago
      > And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason. In my experience, that is a state that would never end. It would work for a month, then break and would never get fixed again, and would fall into abyss of normalized deviance.
      - swsieber 8y ago
        Ah, that's too bad. We have one managed by yarn where I work, and it's only broken on me once. I occasionally get asked for help (maybe 1/3years/person) when somebody gets a cryptic error (well, not that cryptic, but they ask me because it's git related) from it, and rerunning the hook installation task has always fixed it.
  - bmj 8y ago
    This assumes that we are currently using a sane system. But your point is well-taken.
  - ninkendo 8y ago
    I'm not entirely sure I want to sit through a 10 minute linting process every time I do a quick `git add -A && git commit -m WIP` locally. Why does it need to be a pre-commit hook instead of a simple PR check? PR checks obviously need to be done anyway.
    - dean177 8y ago
      10 minutes? A strategy I have used is: - only lint the files that have changed - only apply lint rules that can be auto-fixed This usually takes less than a second (short enough that you can't really tell the difference) and the developer doesn't have to do anything .
      - ninkendo 8y ago
        > 10 minutes? Yes. I work in a codebase that's 30GB checked out. It takes a long time to run our automated checks. That's why they happen on the server, when I make a pull request. The upshot is the same: it doesn't go to master until checks pass. But who gives a shit about what I'm committing locally? I reserve the right to save my work even if things aren't compiling. You (my teammate) won't see it anyway, it's all locally on my machine. Why do you care?
    - purple_ducks 8y ago
      Your local pre-commit hooks are separate to your remote pre-commit hooks.
      - ninkendo 8y ago
        There's no such thing as a remote pre-commit hook. Do you mean a pre-push hook? That's a different story, but even then what you really want is to just deny access to shared branches, except to your CI system, which will run your checks before allowing you to merge. GitHub/GitLab/BitBucket/etc all have this kind of system, it's not new or interesting.
    - asaph 8y ago
      git commit -m WIP I hope you're rebasing that terrible commit message away before pushing this remotely.
  - catdog 8y ago
    > A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures. Omg don't use commit hooks for that, just make it as easy to use as possible for the developer (e.g. integration into the editor/IDE). For verifying such things CI is the way to go. Simply never commit directly to your development branch, use feature branches and pull/merge requests. 1. Someone else (ideally the most experienced Person(s) available but even any second pair of eyes is better than nothing) can and should review the code 2. Hook it up to the CI, the CI should merge it into the target branch locally and do its thing, as long as a pull request fails the CI it will not be merged Software (e.g. Gitlab) to implement such a workflow is freely available, you just have to set it up but that's worth the effort.
- ravenstine 8y ago
  Oh god, nobody effing documents anything. It's the bane of my existence. So much time would be saved if people simply documented things along the way.
  - BerislavLopac 8y ago
    This can be a double-edged sword when it comes to coding, as code and documentation can very easily fall out of sync. I am in favour of trying to write self-documenting code, with clear unit and variable names, with an automated system to convert that to a human-readable format. Any separate documentation should focus on more areas that are not easily concluded from the code -- like intent, architecture and the like.
    - noir_lord 8y ago
      Documentation of code tooling is terrible. I still don't know why we haven't stolen the Photoshop layers paradigm and applied it to code I should be able to toggle a shallow layer and deep layer all from a single 'file' So the you'd be able to have architectural notes in the deep layer etc. In many ways our tools are stuck in time.
      - organsnyder 8y ago
        Fascinating idea. Though from my experience with a crude approximation of part of it—Javadoc (or the equivalent) that's folded by the IDE—keeping the deeper layers up-to-date would be an uphill battle at most organizations.
      - oofoe 8y ago
        Actually, the old Forth block editors did this with their screens and shadow-screens. The normal unit of editing work in original Forth was a 1024 byte "page" called a SCREEN. You would write your code in an editor that arranged it as 16 lines of 64 characters. At the touch of a key (usually), you could swap to the shadow screen which would have the documentation on it. By convention, shadow screen comments were placed on the same line as the code they were remarking on, so everything was usually co-located. By abusing autorepeat, it was even possible to "flicker" the code and documentation to see both at once. Something like CWEB or org-mode permits interleaving code with comments, but it's one dimensional and breaks your flow when editing.
ryandrake 8y ago
I've worked with people who struggled to get code to merely compile--and not just in CompSci 101 back in university where this was at least 80% of the programming students. In actual companies where they were hired as software engineers. Granted, they don't last long.
- sys_64738 8y ago
  A lot of those folks see compilation success meaning program task is now complete. Some slip through the cracks and graduate.
yread 8y ago
Perhaps they meant to say compile on the first try. Then you need to have at least some attention to detail
sys_64738 8y ago
Not every development language requires compilation. E.g. python
- organsnyder 8y ago
  It's still getting compiled at some point.
  - sys_64738 8y ago
    At runtime, which is why you need unit tests and linting as part of your development process.
- davvolun 8y ago
  Still requires syntactic correctness to be interpreted. The fact it doesn't generate compiled objects is pedantry.
  - ken 8y ago
    There's plenty of things which are only caught if actually run. I've certainly seen coworkers push code like: if case_that_im_not_going_to_bother_trying_to_test: obj.method_which_doesnt_exist()
    - catdog 8y ago
      That's the downside of duck typing, could as well be `obj.method_which_might_get_created_at_some_point_at_runtime()`
      - heavenlyblue 8y ago
        I rarely see code in python that I would both like to touch and that uses techniques of this sort.
ken 8y ago
You've been lucky, then. At half the companies I've worked for, there's that One Person who regularly breaks the build for everybody by checking in code that doesn't even compile. This is 98% of why I push for continuous integration. I don't care about unit tests for their own sake, and I don't bother for my personal projects. I only want CI on a team so that when it turns red, there's an unbiased third-party building the code, and I can simply point to it and "the build is broken, please fix". Otherwise, I have to have the same conversation every week, and it always begins with "Oh, I don't think I caused that!"
- james_s_tayler 8y ago
  Impartial enforcers are worth their weight in gold because they never get emotionally exhausted, they never get uncomfortable, they never back down and can't be argued with.

by asaph 8y ago

bmj 8y ago

Agreed. I generally see a lack of attention to detail with regard to things like linting, unit tests, and documentation. Our CI builds fail way too often due to the first two items, which can be easily done via a single build target on a developer's machine.

asaph 8y ago
A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures.
- swsieber 8y ago
  And you can generally set that hook up to be installed automatically through whatever build tool runs your stuff, like gradle for java stuff, or yarn/npm for js/ts stuff. And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason. Attention to detail in developer tooling can reduce the amount of details developers have to pay attention to.
  - SketchySeaBeast 8y ago
    > And if it comes down to it, devs can still skip it if gets into a broken state for whatever reason. In my experience, that is a state that would never end. It would work for a month, then break and would never get fixed again, and would fall into abyss of normalized deviance.
    - swsieber 8y ago
      Ah, that's too bad. We have one managed by yarn where I work, and it's only broken on me once. I occasionally get asked for help (maybe 1/3years/person) when somebody gets a cryptic error (well, not that cryptic, but they ask me because it's git related) from it, and rerunning the hook installation task has always fixed it.
- bmj 8y ago
  This assumes that we are currently using a sane system. But your point is well-taken.
- ninkendo 8y ago
  I'm not entirely sure I want to sit through a 10 minute linting process every time I do a quick `git add -A && git commit -m WIP` locally. Why does it need to be a pre-commit hook instead of a simple PR check? PR checks obviously need to be done anyway.
  - dean177 8y ago
    10 minutes? A strategy I have used is: - only lint the files that have changed - only apply lint rules that can be auto-fixed This usually takes less than a second (short enough that you can't really tell the difference) and the developer doesn't have to do anything .
    - ninkendo 8y ago
      > 10 minutes? Yes. I work in a codebase that's 30GB checked out. It takes a long time to run our automated checks. That's why they happen on the server, when I make a pull request. The upshot is the same: it doesn't go to master until checks pass. But who gives a shit about what I'm committing locally? I reserve the right to save my work even if things aren't compiling. You (my teammate) won't see it anyway, it's all locally on my machine. Why do you care?
  - purple_ducks 8y ago
    Your local pre-commit hooks are separate to your remote pre-commit hooks.
    - ninkendo 8y ago
      There's no such thing as a remote pre-commit hook. Do you mean a pre-push hook? That's a different story, but even then what you really want is to just deny access to shared branches, except to your CI system, which will run your checks before allowing you to merge. GitHub/GitLab/BitBucket/etc all have this kind of system, it's not new or interesting.
  - asaph 8y ago
    git commit -m WIP I hope you're rebasing that terrible commit message away before pushing this remotely.
- catdog 8y ago
  > A pre-commit hook in your revision control system can block checking in code that doesn't pass a lint check. That would reduce your CI build failures. Omg don't use commit hooks for that, just make it as easy to use as possible for the developer (e.g. integration into the editor/IDE). For verifying such things CI is the way to go. Simply never commit directly to your development branch, use feature branches and pull/merge requests. 1. Someone else (ideally the most experienced Person(s) available but even any second pair of eyes is better than nothing) can and should review the code 2. Hook it up to the CI, the CI should merge it into the target branch locally and do its thing, as long as a pull request fails the CI it will not be merged Software (e.g. Gitlab) to implement such a workflow is freely available, you just have to set it up but that's worth the effort.
ravenstine 8y ago
Oh god, nobody effing documents anything. It's the bane of my existence. So much time would be saved if people simply documented things along the way.
- BerislavLopac 8y ago
  This can be a double-edged sword when it comes to coding, as code and documentation can very easily fall out of sync. I am in favour of trying to write self-documenting code, with clear unit and variable names, with an automated system to convert that to a human-readable format. Any separate documentation should focus on more areas that are not easily concluded from the code -- like intent, architecture and the like.
  - noir_lord 8y ago
    Documentation of code tooling is terrible. I still don't know why we haven't stolen the Photoshop layers paradigm and applied it to code I should be able to toggle a shallow layer and deep layer all from a single 'file' So the you'd be able to have architectural notes in the deep layer etc. In many ways our tools are stuck in time.
    - organsnyder 8y ago
      Fascinating idea. Though from my experience with a crude approximation of part of it—Javadoc (or the equivalent) that's folded by the IDE—keeping the deeper layers up-to-date would be an uphill battle at most organizations.
    - oofoe 8y ago
      Actually, the old Forth block editors did this with their screens and shadow-screens. The normal unit of editing work in original Forth was a 1024 byte "page" called a SCREEN. You would write your code in an editor that arranged it as 16 lines of 64 characters. At the touch of a key (usually), you could swap to the shadow screen which would have the documentation on it. By convention, shadow screen comments were placed on the same line as the code they were remarking on, so everything was usually co-located. By abusing autorepeat, it was even possible to "flicker" the code and documentation to see both at once. Something like CWEB or org-mode permits interleaving code with comments, but it's one dimensional and breaks your flow when editing.

ryandrake 8y ago

I've worked with people who struggled to get code to merely compile--and not just in CompSci 101 back in university where this was at least 80% of the programming students. In actual companies where they were hired as software engineers. Granted, they don't last long.

sys_64738 8y ago
A lot of those folks see compilation success meaning program task is now complete. Some slip through the cracks and graduate.

yread 8y ago

Perhaps they meant to say compile on the first try. Then you need to have at least some attention to detail

sys_64738 8y ago

Not every development language requires compilation. E.g. python

organsnyder 8y ago
It's still getting compiled at some point.
- sys_64738 8y ago
  At runtime, which is why you need unit tests and linting as part of your development process.
davvolun 8y ago
Still requires syntactic correctness to be interpreted. The fact it doesn't generate compiled objects is pedantry.
- ken 8y ago
  There's plenty of things which are only caught if actually run. I've certainly seen coworkers push code like: if case_that_im_not_going_to_bother_trying_to_test: obj.method_which_doesnt_exist()
  - catdog 8y ago
    That's the downside of duck typing, could as well be `obj.method_which_might_get_created_at_some_point_at_runtime()`
    - heavenlyblue 8y ago
      I rarely see code in python that I would both like to touch and that uses techniques of this sort.

ken 8y ago

You've been lucky, then. At half the companies I've worked for, there's that One Person who regularly breaks the build for everybody by checking in code that doesn't even compile. This is 98% of why I push for continuous integration. I don't care about unit tests for their own sake, and I don't bother for my personal projects. I only want CI on a team so that when it turns red, there's an unbiased third-party building the code, and I can simply point to it and "the build is broken, please fix". Otherwise, I have to have the same conversation every week, and it always begins with "Oh, I don't think I caused that!"

james_s_tayler 8y ago
Impartial enforcers are worth their weight in gold because they never get emotionally exhausted, they never get uncomfortable, they never back down and can't be argued with.