Live data from Hacker News

Software Development at 1 Hz

medium.com

41–50 of 121 posts

Re: Software Development at 1 Hz

#41
> At the same time I cannot use toy languages that have no compile time type checking

This guy seems like and sounds like a serious developer, so I'm totally confused by this statement.

Dynamic languages that don't do compile time type checking are not toys.

I used to only write in Java or C++, but I think it's a stage of maturity as a developer to realize that you can develop code that can take arguments with the assumption that the objects sent in are of types that will have the behavior you need to work with them.

If you argue that the code is faster when it is compiled- that's fine, and I agree, and that's good, if it matters.

If you argue that you need types because otherwise you can't be safe, I'm sorry, but that's like being a helicopter-parent. Sometimes maybe you can't trust what is calling your code even when you give it trust, and that's valid; just like as a parent, sometimes the child really needs that level of micromanagement. But, for a lot of if not most of practical web development, you can use dynamic typing, and most children do not need that level of micromanagement.

There's nothing wrong with languages that provide type checking, but it isn't necessarily a deficiency when it's not there.

Re: Software Development at 1 Hz

#42
post #30
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 a two steps forward two steps back kind of situation. For a while we just had HTML+PHP... save it, alt tab, reload. Then we had servers that have to boot and that took a step back. Then we had hot reloading servers and everything is fast again. Then we added asset complication and things took 30 seconds to process again. Now we're working on incremental building of assets to get back that speed again.

Re: Software Development at 1 Hz

#43
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.

I agree. That's the experience I have doing web development in Lisp. Most other languages have at least a deployment step, even if it's a scripting language that doesn't require compilation.

I'm getting this with a language that has a very high performance native compiler. And it's sad not more people use this.

Re: Software Development at 1 Hz

#44

Earlier quoted context omitted.

If 8 minutes sounds like a lot... turnaround times when you work with FPGA code can be hours (and months if you're taping out an ASIC). After having to cope with that for a while, I've found that even with software I think a lot more before writing any code, and now I find myself stepping into the debugger much less often. (My point is: debugging first in your head is yet another skill that should really be taught to…

> debugging first in your head is yet another skill that should really be taught to everybody but isn't Along with smelting iron. I don't know why people advocate skills one doesn't need, saying "but they make you better". Skills you don't need will atrophy, because you don't need them. Conversely, skills you need with strengthen. Why would I debug first in my inaccurate head when I have a perfectly accurate debugger…

Being unable to run through code in your head and fully conceptualise a codebase is a great way to introduce subtle integration-level bugs that escape unit testing.

Re: Software Development at 1 Hz

#45
post #7

When I write code, I have this mental model of how the world (application) works. I write some lines of code based on it, and then test the code. More often than not, something happened that I hadn't thought about, and my mental model is updated. This summer I worked on an application where it took 8 minutes to see the effect of changed code. Between each iteration, I had forgot most of the assumptions I had made. So…

The really interesting thing is that while I'm completely happy to spend 30 mins writing line after line of code to implement some algorithm, winding up with >100 lines and only compiling at the end, if it takes more than around 30 seconds to compile I'll lose my train of thought entirely.

So I understand the concept from the point of view of task-switching.

But a lot of people in the comments allude to needing a feedback loop for each and every line of code, which sounds absolutely horrifying to me - is that really what development is like in some environments? you can't really be sure of what a single line of code is going to do?

Re: Software Development at 1 Hz

#46

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).

Doesn't that also remove the need for discipline? So the last vestiges of 'engineering' that so many programmers aspire to vanish, they can blame their tools, and the only development challenges are found in the tools themselves (perhaps already true to some extent).

This sounds depressing.

Re: Software Development at 1 Hz

#47

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 and able to solve much complicated problems when they arise.

Re: Software Development at 1 Hz

#48

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…

> 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.

Do you really need to compile/run something like fizzbuzz? What if you're writing code that can't be run, such as when modifying a larger piece of code that won't run until all modifications are made?

Isn't there some value in being able to verify correctness of code just by looking at it for a few seconds? Surely you can overlook some things, but with practice probably a lot less than people think.

Re: Software Development at 1 Hz

#49

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).

The best method is to automatize your methods.

Re: Software Development at 1 Hz

#50
post #46

Earlier quoted context omitted.

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).

Doesn't that also remove the need for discipline? So the last vestiges of 'engineering' that so many programmers aspire to vanish, they can blame their tools, and the only development challenges are found in the tools themselves (perhaps already true to some extent). This sounds depressing.

> the only development challenges are found in the tools themselves (perhaps already true to some extent).

Definitely true on the web side of things. Bootstrap+React+Angular+jQuery+whatever else, minify, deploy on docker, done.

Post reply on HN