4 ms·

> 2: Everybody may be right that's the one I was expecting to be there. Computer Science may be a science, but software engineering (to say nothing of "program

> 2: Everybody may be right that's the one I was expecting to be there. Computer Science may be a science, but software engineering (to say nothing of "programming") is a series of scar tissue in bits, intermixed with so many different expectations I expect that if a webpage encounters an error, it tells me that it did; most managers expect that error handling is for paranoid people and slows down ship velocity. Thus, all software is terrible, just to different audiences

wnolens 4y ago
> but software engineering (to say nothing of "programming") is a series of scar tissue in bits Lol. I will use this from now on: A software engineer is a computer scientist with scar tissue.
- eastbound 4y ago
  The more I work with The Cloud, the more I feel like software is alive: Things that used to work, don’t, a piece that works well becomes bloated with logs that needs to be saved and inspected regularly, surgery is sometimes needed to hot-replace log4j with 1.18.2, and anything you connect to the internet can be infected by diseases. Can’t wait for AI-specialized psychologists to intervene to understand how its infancy is related to their adulthood problems.
  - andirk 4y ago
    It is often very obvious to those who need to edit "legacy" code, which so often just means bad code; it didn't have to be that way ever.
  - wnolens 4y ago
    Along these lines, you can't attach a debugger anywhere and dissect it like some lifeless cadaver. You have to rely on having taught the system in advance to report what's going on and draw conclusions from a set of signals.
seti0Cha 4y ago
Beyond that, engineers have different ways of approaching problems and of crafting the code. TDD may actually work great for one engineer, but be terribly disruptive to another. Engineers working in IDEs tend to have a different idea about what constitutes readable code than ones working in basic editors. There is no one way of writing code that is ideal for every coder.
- mdaniel 4y ago
  TDD, as the top-most comment correctly points out <https://news.ycombinator.com/item?id=32509268 https://news.ycombinator.com/item?id=32509268>, relies on having requirements against which to test, and as very best I can tell, requirements aren't "Agile" because (pick one:) (the users don't even know what they want || there's never time to do it right, but there's always time to do it over) don't even get me started on the "basic editor" versus IDE war; that's a topic that 100% of the time grinds my gears
  - Huggernaut 4y ago
    Agile isn't about requirements in the sense of "all behaviour of this project must be specified up front" but that doesn't mean for small slices of validated or to be validated behaviour we can't say "this is what it should do" (otherwise nothing sensible would ever get written?) From that point of view, a developer has what they need to move forward with TDD (or any other process of their choosing).
    - dllthomas 4y ago
      I've been wanting a documentation system that lets me "cite" tests in support of a claim, such that when a test fails the programmer can see what claims that test was meant to support, which is crucial context in deciding how to fix the code, test, and/or docs.
      - brabel 4y ago
        You just need a testing framework that supports specifying context. I write my JVM tests mostly using Spock[1] as it's absolutely great at letting me specify, and ecouraging me to do so, as much context as I can. It may look something like this (this example is loosely based on Spock using Geb[2]): @Narrative(''' Users can choose to authenticate using method A or B. This test makes sure that users can choose one or the other, go back and change their decision later, and complete the procedure with either method. ''') class AuthenticationMethodsSpec extends Specification { def 'Users can choose method A'() { given: 'the user goes to the login page' goTo(LoginPage) when: 'the user chooses method A' page.click('methodA') then: 'the user goes to the method A login page' at LoginMethodA } Error messages are great too... and the tests, at least when written as above, with actual contextual information everywhere necessary, are much better than the usual JUnit abominations you're likely to find in Java shops. It may look superficially similar to Cucumber, but it's IMO much better because it's just Groovy code (and I happen to really like Groovy, some people have trouble with it because it's "not exactly like Java"), no custom parsing of text-based stuff and other complex gimmicks. [1] https://spockframework.org/spock/docs/2.1/index.html https://spockframework.org/spock/docs/2.1/index.html [2] https://www.gebish.org/ https://www.gebish.org/

wnolens 4y ago

> but software engineering (to say nothing of "programming") is a series of scar tissue in bits Lol. I will use this from now on: A software engineer is a computer scientist with scar tissue.

eastbound 4y ago
The more I work with The Cloud, the more I feel like software is alive: Things that used to work, don’t, a piece that works well becomes bloated with logs that needs to be saved and inspected regularly, surgery is sometimes needed to hot-replace log4j with 1.18.2, and anything you connect to the internet can be infected by diseases. Can’t wait for AI-specialized psychologists to intervene to understand how its infancy is related to their adulthood problems.
- andirk 4y ago
  It is often very obvious to those who need to edit "legacy" code, which so often just means bad code; it didn't have to be that way ever.
- wnolens 4y ago
  Along these lines, you can't attach a debugger anywhere and dissect it like some lifeless cadaver. You have to rely on having taught the system in advance to report what's going on and draw conclusions from a set of signals.

seti0Cha 4y ago

Beyond that, engineers have different ways of approaching problems and of crafting the code. TDD may actually work great for one engineer, but be terribly disruptive to another. Engineers working in IDEs tend to have a different idea about what constitutes readable code than ones working in basic editors. There is no one way of writing code that is ideal for every coder.

mdaniel 4y ago
TDD, as the top-most comment correctly points out <https://news.ycombinator.com/item?id=32509268 https://news.ycombinator.com/item?id=32509268>, relies on having requirements against which to test, and as very best I can tell, requirements aren't "Agile" because (pick one:) (the users don't even know what they want || there's never time to do it right, but there's always time to do it over) don't even get me started on the "basic editor" versus IDE war; that's a topic that 100% of the time grinds my gears
- Huggernaut 4y ago
  Agile isn't about requirements in the sense of "all behaviour of this project must be specified up front" but that doesn't mean for small slices of validated or to be validated behaviour we can't say "this is what it should do" (otherwise nothing sensible would ever get written?) From that point of view, a developer has what they need to move forward with TDD (or any other process of their choosing).
  - dllthomas 4y ago
    I've been wanting a documentation system that lets me "cite" tests in support of a claim, such that when a test fails the programmer can see what claims that test was meant to support, which is crucial context in deciding how to fix the code, test, and/or docs.
    - brabel 4y ago
      You just need a testing framework that supports specifying context. I write my JVM tests mostly using Spock[1] as it's absolutely great at letting me specify, and ecouraging me to do so, as much context as I can. It may look something like this (this example is loosely based on Spock using Geb[2]): @Narrative(''' Users can choose to authenticate using method A or B. This test makes sure that users can choose one or the other, go back and change their decision later, and complete the procedure with either method. ''') class AuthenticationMethodsSpec extends Specification { def 'Users can choose method A'() { given: 'the user goes to the login page' goTo(LoginPage) when: 'the user chooses method A' page.click('methodA') then: 'the user goes to the method A login page' at LoginMethodA } Error messages are great too... and the tests, at least when written as above, with actual contextual information everywhere necessary, are much better than the usual JUnit abominations you're likely to find in Java shops. It may look superficially similar to Cucumber, but it's IMO much better because it's just Groovy code (and I happen to really like Groovy, some people have trouble with it because it's "not exactly like Java"), no custom parsing of text-based stuff and other complex gimmicks. [1] https://spockframework.org/spock/docs/2.1/index.html https://spockframework.org/spock/docs/2.1/index.html [2] https://www.gebish.org/ https://www.gebish.org/