Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Development at 1 Hz

medium.com

Post reply on HN
Print view View original

51–60 of 121 posts

Re: Software Development at 1 Hz

#51

Post by btbuildem »

pags wrote: post #30
nojvek wrote: post #9

I am a huge believer of In my new team I got it from 30s to 5s and the effects have been amazing. I have to thank VScode and Gulp to make this possible. With typescript vscode does fast parsing of your code on every keystroke and gives squigglys instantly. On every save, gulp does its magic and vscode runs the problem matcher and shows more squiggly on my editor. The browser knows when a file has changed and refreshe…

Web engineers are waiting for stuff to compile these days? I thought things were supposed to be moving forward, not backward.

It's simultaneously frustrating and entertaining to watch the younger generation toil under the impression that they're inventing something new.

Re: Software Development at 1 Hz

#52

Post by na85 »

mpweiher wrote: post #2

I've been working on/with an environment that gives me feedback on every keystroke. The effect has been amazing, and it's always painful to go back to regular environments. Even traditional Smalltalks or REPLs where I have to do something to execute the current command are jarring. Regular compile/link/debug is painful. Xcode is excruciating.

Why wouldn't you include the name of said environment?

Re: Software Development at 1 Hz

#53

Post by donw »

DougBTX wrote: post #18
nojvek wrote: post #9

I am a huge believer of In my new team I got it from 30s to 5s and the effects have been amazing. I have to thank VScode and Gulp to make this possible. With typescript vscode does fast parsing of your code on every keystroke and gives squigglys instantly. On every save, gulp does its magic and vscode runs the problem matcher and shows more squiggly on my editor. The browser knows when a file has changed and refreshe…

This is a problem I'm having at the moment, 20s webpack builds with ts-loader, plus other build steps running in VS 2015. Seems I need to drop ts-loader, and build more directly. Are your build files available to look at somewhere?

That sounds... high. No guarantees that I can help with your current stack, but my email is in my profile if you'd like to run your setup by me.

Re: Software Development at 1 Hz

#54

Post by [deleted] »

btbuildem wrote: post #51
pags wrote: post #30

Earlier quoted context omitted.

Web engineers are waiting for stuff to compile these days? I thought things were supposed to be moving forward, not backward.

It's simultaneously frustrating and entertaining to watch the younger generation toil under the impression that they're inventing something new.

[deleted]

Re: Software Development at 1 Hz

#55

Post by taeric »

StavrosK wrote: post #40
castratikron wrote: post #37

Earlier quoted context omitted.

Right. If I would have worked on this again, the first thing I'd do is come up with some way of automatically testing the code.

Sure, but my point is that being forced to be more methodical isn't a good thing. Not needing to be methodical is better (because your tools will catch your mistakes for you).

This is... What?

I'm not all in on what I call "Poirot's doctrines," but there is almost always room for method. I grant that some methods aren't needed and speed is always of high value.

However, speed of bouncing from beep to beep in your tools are not always faster than stepping back and thinking.

As an example, no amount of fast feedback will help you complete all of the Euler problems.

Re: Software Development at 1 Hz

#57

Post by taeric »

StavrosK wrote: post #36
castratikron wrote: post #34

I wrote numerical code for a while, it simulated a magnetic material. It would take hours to run a simulation long enough to be able to verify that it was correct. Make a change, wait five hours, check if the change worked. I eventually started keeping a journal of every code change I made, along with the hash of the binary that it created. I could use this to make several independent changes and run them all at the…

> High latency feedback forces you to be more methodical in your development and think about the changes you're making. So does not having tests.

Oddly... The most tested code bases I have worked in had similar problems. They had tested and designed themselves into a solution that did not lend itself to changes. To the point that making a change required reasoning about several micro services and integration test packages.

Again, there are no panaceas.

Re: Software Development at 1 Hz

#58

Post by userbinator »

darthdeus wrote: post #47
castratikron wrote: post #34

I wrote numerical code for a while, it simulated a magnetic material. It would take hours to run a simulation long enough to be able to verify that it was correct. Make a change, wait five hours, check if the change worked. I eventually started keeping a journal of every code change I made, along with the hash of the binary that it created. I could use this to make several independent changes and run them all at the…

> High latency feedback forces you to be more methodical in your development and think about the changes you're making. This! People rely on their fancy REPLs and super fast feedback loops and 1000 unit tests too much these days. What do you actually do when you can't run the code? What if you have to debug it just by reading it? There's a lot to be said about being efficient with trivial changes vs being methodical…

This is exactly the reason why I actually quite strongly discourage teaching programming by starting with IDEs. Far too often I see beginners fall into what I call "programming tunnel vision" where they repeatedly make very tiny and often random changes to a piece of code in an attempt to get it to compile or produce the right result, seeming to completely abandon any thoughts about the overall goal. A lower latency feedback only encourages this behaviour more. The same phenomenon also happens if you give them a debugger --- they spend plenty of time just stepping through the code without any good sense of the bigger picture. Maybe it feels productive, but it's not. Their attention is too preoccupied with the feedback that they do not think deeply enough about their solution, and as a result, overall code quality often also suffers.

Instead, I believe in thinking carefully about the problem. Close your eyes and visualise the program and its data and control flow in your mind, then write the code. Use a whiteboard or even pencil and paper to collect your thoughts and get a good mental model of what you're trying to accomplish. Block out all other distractions and focus on the problem.

Many others I've talked to are in disbelief when I tell them I can spend an hour writing several hundred lines of code that compiles and works flawlessly the first time, but this is what careful thought will allow. Even with a very fast feedback loop you may spend several times longer fiddling with the code until you get something that seems to work, but actually doesn't in all cases precisely because you did not ever think about those cases while you were fiddling with it and had your attention focused on getting that next dose of feedback.

Re: Software Development at 1 Hz

#59

Post by userbinator »

ctdonath wrote: post #17

This is why interview code tests are... badly misguided. Most "fizzbuzz" screening is grossly artificial, denying one the feedback loops which are a critical element of productivity, and without which one is relegated to spending time manual checking what automation does almost instantly. I rely heavily on the IDE reminding me of things, and quick compile/run cycles verifying correctness, rather than trying to think…

I would argue that if you can't write a correct FizzBuzz without needing to compile and run it, or even worse, an IDE to hold your hand, you don't actually understand what's happening and are just leaning on a crutch.

I rely heavily on the IDE reminding me of things, and quick compile/run cycles verifying correctness, rather than trying to think thru a myriad of special cases.

The peril of that sort of workflow is that you often won't realise the importance of those special cases until it's too late to change things easily. "It looks like it works, it compiles and runs" --- I've heard this sentiment from such IDE users many times, and yet when I inspect their code, they inevitably missed something important.

Someone once gave me a phrase I like to keep in mind when programming: "How can you tell the machine what to do if you're not even sure how to do it yourself?"

Re: Software Development at 1 Hz

#60

Post by WhitneyLand »

userbinator wrote: post #58
darthdeus wrote: post #47

Earlier quoted context omitted.

> High latency feedback forces you to be more methodical in your development and think about the changes you're making. This! People rely on their fancy REPLs and super fast feedback loops and 1000 unit tests too much these days. What do you actually do when you can't run the code? What if you have to debug it just by reading it? There's a lot to be said about being efficient with trivial changes vs being methodical…

This is exactly the reason why I actually quite strongly discourage teaching programming by starting with IDEs. Far too often I see beginners fall into what I call "programming tunnel vision" where they repeatedly make very tiny and often random changes to a piece of code in an attempt to get it to compile or produce the right result, seeming to completely abandon any thoughts about the overall goal. A lower latency…

>>"I quite strongly discourage teaching programming by starting with IDEs..."

>>"...also happens if you give them a debugger..."

1). I assume you can cite no research supporting the idea that new programmers are better off with your recommendations?

2). Your idea doesn't seem to take into account that different people think in different ways. I believe this approach was good for you. But as far as we know you could be in the minority right?

For these reasons I don't think there is enough data to make blanket recommendations against IDEs and debuggers.

Post reply on HN