https://pistepal.app/ - a ski map app - built at breakneck speed over the last few months. I believe this is the only ski map app that offers turn-by-turn navigation!
Still a little bit rough around the edges but hopefully will be / is in decent enough shape for the start of the ski season (just about happening now..)
Currently figuring out the right balance of free tier & daily trial. Priced at $10/month and therefore significantly undercutting the competition, hopefully this is enough to gain entry into the market. (May need a more generous daily trial though, admittedly 10 minutes is not really enough to actually try it out on the mountain).
Seems ad spend is necessary to get any kind of traction...
Hey Dan, I think you're going to love what I've built.
The next release (a couple of days out) displays the relative altitude for all of your buddies - so you can immediately see who's above or below you.
On the iPhone, that info also lives in a Live Activity on the lock screen so you don't have to take your gloves off to see that essential info! (Android lock screen support will be coming right after).
If you'd like to help test the feature out, I'd really appreciate it - just drop me a message via https://pistepal.app/support and I'll link you up with an annual subscription.
Yeah very specifically above or below. You don’t need to share exact location data (although you’d still need access to it on the local device) - just elevation.
Don’t over engineer it - just an indicator about how much further down the slope or back up the slope the rest of the pack is.
I find it annoyingly frequent that I’m either waiting for mates who have bombed off ahead because I didnt see them pass, or I’m waiting at the bottom for mates who are up the slope waiting for me because they think I’m behind ! Literally hours wasted each trip doing this.
You might think a quick phone call is the solution to this but that’s too clunky. It’d be nice to take out my phone and just quickly see something on the home screen indicating this, or on the watch app.
That's a great idea. A lock screen widget could work really well here, showing the relative elevations of your buddies. You'd have to take your phone out - but you wouldn't have to take your gloves off!
Would also think about ways in which the app could indicate the elevation of others without having to stop, remove the gloves, picking the phone from my pocket, looking at the screen, and putting everything back on every time.
Maybe having different kinds of (infrequent) beeping in specific cases:
- when I'm last
- when I'm first
This could get old quite quickly thought, just a thought.
The app is definitely still a bit rough around the edges but it was developed in breakneck speed over the last few months - I've probably seen an overall 5x acceleration over pre-agentic development speed.
I tried to get VLC to open up a PDF and it didn't do as I asked. Should I cry censorship at the VLC devs, or should I accept that all software only does as a user asks insofar as the developers allow it?
I use it all the time, and it has accelerated my output massively.
Now, I don't trust the output - I review everything, and it often goes wrong. You have to know how to use it. But I would never go back. Often it comes up with more elegant solutions than I would have. And when you're working with a new platform, or some unfamiliar library that it already knows, it's an absolute godsend.
I'm also damn proud of my own hand-crafted code, but to avoid LLMs out of principal? That's just luddite.
20+ years of experience across game dev, mobile and web apps, in case you feel it relevant.
I have a hard time being sold on “yea it’s wrong a lot, also you have to spend more time than you already do on code review.”
Getting to sit down and write the code is the most enjoyable part of the job, why would I deprive myself of that? By the time the problem has been defined well enough to explain it to an LLM sitting down and writing the code is typically very simple.
You're giving the game away when you talk about the joy LLMs are robbing from you. I think we all intuit why people don't like the idea of big parts of their jobs being automated away! But that's not an argument on the merits. Our entire field is premised on automating people's jobs away, so it's always a little rich to hear programmers kvetching about it being done to them.
I naively bought into the idea of a future where the computers do the stuff we’re bad at and we get to focus on the cool human stuff we enjoy. If these LLMs were truly incredible at doing my job I’d pack it up and find something else to do, but for now I’m wholly unimpressed, despite what management seems to see in it.
Well, I've spent my entire career writing software, starting in C in the 1990s, and what I'm seeing on my dev laptop is basically science fiction as far as I'm concerned.
Hey both things can be true. It’s a long ways from the AI renaissances of the past. There’s areas LLMs make a lot of sense. I just don’t find them to be great pair programming partners yet.
I think people are kind of kidding themselves here. For Go and Python, two extraordinarily common languages in production software, it would be weird for me at this point not to start with LLM output. Actually building an entire application, soup-to-nuts, vibe-code style? No, I wouldn't do that. But having the LLM writing as much as 80% of the code, under close supervision, with a careful series of prompts (like, "ok now add otel spans to all the functions that take unpredictable amounts of time")? Sure.
I'm glad that works for you. Ultimately I think different people will prefer different ways of working. Often when I'm starting a new project I have lots of boilerplate from previous ones I can bootstrap off of. If it's a new tool I'm unfamiliar with I prefer to stumble through it, otherwise I never fully get my head around it. This tends to not look like insane levels of productivity, but I've always found in the long run time spent scratching my head or writing awkward code over and over again (Rust did this to me a lot in the early days) ends up paying off huge dividends in the long run, especially when it's code I'm on the hook for.
What I've found frustrating about the narrative around these tools; I've watched them from afar with intrigue but ultimately found that method of working just isn't for me. Over the years I've trialed more tools than I can remember and adopted the ones I found useful, while casting aside ones that aren't a great fit. Sometimes I find myself wandering back to them once they're fully baked. Maybe that will be the case here, but is it not valid to say "eh...this isn't it for me"? Am I kidding myself?
In my last microservice I took over tests were written by juniors and med. devs using cursor and it was a big blob of generated crap that pass the test, pass the coverage % and are absolute useless garbage
> Our entire field is premised on automating people's jobs away, so it's always a little rich to hear programmers kvetching about it being done to them.
Watch out, you’re giving your game away.
My job is about enabling analysis that was previously done ad hoc and informally. If I’m harming people then that’s something I have to take responsibility for, but it’s also caused not by my direct contribution but by the larger system that I’m working within.
I expressively don’t want to automate away work when that will just result in more profit for private owners and less income for regular working people.[1] And I also don’t want to automate work if that means shifting drudgery to some worker to fill in that freed up time.
And how does this contradict what “we” are doing and stand for!? We criticize technology on this board all the time!
But it’s nice to have the priorities of such a prominent member on the record.
[1] But I DO want to automate work in the hypothetical society where we all own the automation and thus the only thing we are deprived of is drudgery.
The parts worth thinking about you still think about. The parts that you’ve done a million times before you delegate so you can spend better and greater effort on the parts worth thinking about.
This is where the disconnect is for me; mundane code can sometimes be nefarious, and I find the mental space I'm in when writing it is very different than reviewing, especially if my mind is elsewhere. The best analogy I can use is a self-driving car, where there's a chance at any point it could make an unpredictable and potentially fatal move. You as the driver cannot trust it but are not actively engaged in the act of driving and have a much higher likelihood of being complacent.
Code review is difficult to get right, especially if the goal is judging correctness. Maybe this is a personal failing, but I find being actively engaged to be a critical part of the process; the more time I spend with the code I'm maintaining (and usually on call for!) the better understanding I have. Tedium can sometimes be a great signal for an abstraction!
The parts I've done a million times before take up... maybe 5% of my day? Even if an LLM replaced 100% of this work my productivity is increased by the same amount as taking a slightly shorter lunch.
> The parts that you’ve done a million times before you delegate
That's where I'm confused. I've been coding for more than 20 years, and every task I ever did was different from the other ones. What kind of task do you do a million times before realizing that you should script it in bash or Python?
First of all, it’s not tedious for a lot of us. Writing characters themselves is not a lot of time. Secondly, we don’t work in a waterfall model, even on the lowest levels, so the code quantity in an iteration is almost always abysmal or small. Many-many times it’s less than articulate it in English. Thirdly, if you need a wireframe for your code, or a first draft version, you can almost always copy-paste or generate them.
I can imagine that LLM is really helpful in some cases for some people. But so far, I couldn’t find a single example when I and simple copy-pasting wouldn’t have been faster. Not even when I tried it, not when others showed me how to use it.
Because the tedious parts was done long ago while learning the tech. For any platform/library/framework you've been using for a while, you have some old projects laying around that you can extract the scaffolding from. And for new $THING you're learning, you have to take the slow approach anyway to get its semantic.
For me it's typically wrong not in a fundamental way but a trivial way like bad import paths or function calls, like if I forgot to give it relevant context.
And yet the time it takes me to use the LLM and correct its output is usually faster than not using it at all.
Over time I've developed a good sense for what tasks it succeeds at (or is only trivially wrong) and what tasks it's just not up for.
> but to avoid LLMs out of principal? That's just luddite.
Do you double check that the LLM hasn't magically recreated someone else's copyrighted code? That's just irresponsible in certain contexts.
> in case you feel it relevant.
Of course it's relevant. If a 19 year old with 1 year of driving experience tries to sell me a car using their personal anecdote as a metric I'd be suspicious. If their only salient point is that "it gets me to where I'm going faster!" I'd be doubly suspicious.
> and I expect LLMs to become such ubiquitous table-stakes
Unless they develop entirely new technology they're stuck with linear growth of output capability for input costs. This will take a very long time. I expect it to be abandoned in favor of better ideas and computing interfaces. "AI" always seems to bloom right before a major shift in computing device capability and mobility and then gets left behind. I don't see anything special about this iteration.
> that I don't think anyone will really care in the long run.
There are trillions of dollars at stake and access to even the basics of this technology is far from egalitarian or well distributed. Until it is I would expect people who's futures and personal wealth depends on it to care quite a bit. In the meanwhile you might just accelerate yourself into a lawsuit.
That's really a non-issue. Anything copyrightable is non-trivial in length and complexity to the point that an LLM is not going to verbatim output that.
>>> Please write a hello world app in java
```java
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
```
Does it though? I've developed in remote VMs before and the advantages are clear, but having a fully containerized development environment is really nice too because you can tear the whole thing down and rebuild at the drop of a hat. You can achieve that with a VM and scripts, but a Dockerfile is very lightweight and standard.
Edit: Unless you literally mean "editing code in a container with vi". In which case yes I'd go for the VM too!
I am currently doing development on a VM with remote SSH, but I use the terminal on said VM to run a docker container when I need to actually run and build the thing, so it is possible to get both remote SSH tooling and containerization benefits, without needing to build a docker container and SSH into it from vs code, which might be what GP was saying.
