HN user

nsb1

295 karma
Posts0
Comments102
View on HN
No posts found.

A lot of the complaints about these tools seems to revolve around their current lack of ability to innovate for greenfield or overly complex tasks. I would agree with this assessment in their current state, but this sentiment of "I will only use AI coding tools when they can do 100% of my job" seems short-sighted.

The fact of the matter, in my experience, is that most of the day to day software tasks done by an individual developer are not greenfield, complex tasks. They're boring data-slinging or protocol wrangling. This sort of thing has been done a thousand times by developers everywhere, and frankly there's really no need to do the vast majority of this work again when the AIs have all been trained on this very data.

I have had great success using AIs as vast collections of lego blocks. I don't "vibe code", I "lego code", telling the AI the general shape and letting it assemble the pieces. Does it build garbage sometimes? Sure, but who doesn't from time to time? I'm experienced enough notice the garbage smell and take corrective action or toss it and try again. Could there be strange crevices in a lego-coded application that the AI doesn't quite have a piece for? Absolutely! Write that bit yourself and then get on with your day.

If the only thing you use these tools for is doing simple grunt-work tasks, they're still useful, and dismissing them is, in my opinion, a mistake.

I cribbed these from someplace - slightly different approach:

  ###################################################################
  # Add directory to path
  pathadd() {          
      newelement=${1%/}
      if [ -d "$1" ] && ! echo $PATH | grep -E -q "(^|:)$newelement($|:)" ; then
          if [ "$2" = "after" ] ; then
              PATH="$PATH:$newelement"
          else         
              PATH="$newelement:$PATH"
          fi
      fi
  }
 
  ###################################################################
  # Remove directory from path
  pathrm() {
      PATH="$(echo $PATH | sed -e "s;\(^\|:\)${1%/}\(:\|\$\);\1\2;g" -e \
      's;^:\|:$;;g' -e 's;::;:;g')"
  }
Still Love Telnet 3 years ago

I'm dating myself, but my school had touch-tone service for the same thing. My trusty war-dialing script and I didn't fail to enroll into any class I wanted either. Ahh, the good ol' days.

Not quite ready for prime time, but I've spent the last couple of weeks building a fast, free, parametric part library for makers to use for widget-type parts rather than complex models. I found the current set of part libraries to be to slow and/or cumbersome for my tastes.

It's 100% static and hosted on GitHub pages. It uses WASM versions of OpenSCAD and SQLite for dynamic content with all processing being done in the browser. Parts are added as GitHub issues, and can be added by anyone with a GitHub login

https://parapart.com

Next step: Content!

Note: Currently not mobile-friendly.

100% this. I've interviewed a great many candidates over the years, and the coding exercise has always been an incredibly valuable litmus test. It gives the interviewer a chance to see whether or not the potential employee has the knowledge of the language and skills needed to do the job. If a developer can't even figure out how to do a basic function on demand, how are they going to be able to contribute to the team? If a developer won't do a basic function on demand, then that's an instant disqualification. Anyone can say anything on a resume, and there needs to be a way to validate that it's not just a fabrication.

To be clear, I am making the distinction between "coding exercise" and "brain-teaser". Brain-teasers are not useful in an interview context, and only result in adding stress to an already stressful situation. Simple tasks like "Write a function that rolls two dice and calculates the position of a game piece as it moves around the edge of a game board" are much better. I am not looking for the candidate to give me their masters thesis in a piece of code on demand, I am looking to weed out candidates that clearly don't have the skills to fill the position.

While this is tempting, it falls apart as soon as the development team matures and grows beyond more than a few people. What often happens especially in larger organizations is that bugs and/or changes come up and someone ELSE has to dive in and try to figure out what's going on. It's at this point that dense uncommented code or code that employs every preprocessor trick in the book becomes a huge liability. That "smart" developer just caused an increase in the time it takes to do code maintenance because the poor axe-wielding sap who has to look at it now has to spend a bunch of effort just to figure out what's going on.

Some of you may be thinking, "Then you didn't hire enough smart developers!" (for whatever definition of "smart" we're talking about here). To that I would say, "Maybe not, but I'd rather hire a solid, dependable developer who knows how to write maintainable code over some sort of savant any day of the week."

I've managed a lot of different developer personalities over the years, and the "smartest" ones nearly always produced the worst code for the business overall. In addition, while they were doing this, there were often other quirks that came along for the ride, like 'malicious compliance' with the design, or checking in three features you didn't ask for along with the one that you did. Sometimes it takes some uncomfortable conversations to get these people working with the team, and sometimes it's just impossible. In the latter case, this person just becomes a liability to the team and should probably be encouraged to move on.

Vim Foot Pedal 4 years ago

Someone long ago, probably here, suggested binding the sequence 'K-J' to 'ESC'. Now I don't even have to take my fingers off the home row.

Yeah, but what you're saying is essentially "I don't need the recipe anymore - I can do this by feel", which is awesome, but who then is the recipe for except people who are trying to learn? Maybe throw us a bone :)

Exactly this. It's this sort of thing that annoys me about recipes in general, but bread recipes in particular.

SpaceVim 2.0 4 years ago

The dot command is always what seems lacking in the various emulation layers. Either it doesn't work at all, or doesn't work the way you expect. As a dot command addict, this makes me sad.

Unfortunately there's another angle here which is that the little fish are competing for supply with higher priced, higher volume products like cars, where a 10x increase in one component can be amortized over a much higher total cost and passed on to the customer. Nobody is going to notice an extra couple hundred bucks on the price of a car, but they'll definitely notice when it's on something that itself only costs a couple hundred bucks.

Big consumers are able to outbid even companies like DigiKey because they can afford to spread the cost around. TI had one of its best quarters ever over the last 12 months, but just try to buy TI parts anywhere - they're being priced through the roof. A $0.30 TI regulator was going for $30.00 on the secondary markets. I feel for any small company trying to build hardware right now.