11–20 of 279 posts
https://github.com/agilefreaks/winomni
This is the windows client for a cross device clopboard we worked a while back but dropped because we couldn't get users. Other components: https://github.com/agilefreaks/webomni https://github.com/agilefreaks/droidomni
> A few students came to me asking if I had any ideas for a software project that they could work on outside of class. > I explained an idea for a utility that I had been wanting: A desktop program that monitors my clipboard for URLs and logs them automatically. I think this person misunderstood the students, the student wanted a project to practice programming, not a project to practice project management. The progr…
This is, literally, the error that the entire article works on dispelling.
Anyone can write a rough command line tool that monitors the clipboard and prints to stdout. Writing a usable GUI application is a lot more work. That’s not project management, that’s coding work.
The ratio of project management work to coding isn’t 10:1 or even 100:1 like you’re suggesting.
Honestly I learned this lesson as a young engineer, as I suspect many others did, by giving a project manager an off the cuff answer to "how long will this take". The next month of embarrassingly explaining why I was late every Tuesday and Thursday was enough for me to now take a serious amount of time, come up with a realistic estimate, and then add a lot of buffer. Better to under promise and over deliver.
Only brand-new developers (and Sith?) estimate things in hours. Experienced devs estimate in days, but senior developers won't give you a number in increments smaller than weeks.
Also, any manager who trusts an estimate from a new employee or especially a new developer is an ass. They should have known better, and giving you grief about it is just doubling down on a category error. We've all had that experience, but I'd like it if we all learned to reframe such experiences as abusive. Especially if you're going to be in a position to repeat those sorts of experiences on a new generation. Break the cycle of stupid.
> A few students came to me asking if I had any ideas for a software project that they could work on outside of class. > I explained an idea for a utility that I had been wanting: A desktop program that monitors my clipboard for URLs and logs them automatically. I think this person misunderstood the students, the student wanted a project to practice programming, not a project to practice project management. The progr…
> The programming parts of this would take 2-4 hours This is, literally, the error that the entire article works on dispelling. Anyone can write a rough command line tool that monitors the clipboard and prints to stdout. Writing a usable GUI application is a lot more work. That’s not project management, that’s coding work. The ratio of project management work to coding isn’t 10:1 or even 100:1 like you’re suggesting.
Running the program at start isn't programming, it is putting it in a "run on start" location, helping users do that is a part of managing the project and not programming.
Figuring out what settings a user would want for it is also project management and not programming.
Starting/stopping is just starting and stopping the program, every OS already provides that functionality. Maybe someone would want a better UX, but then you are doing UX work and not programming work.
So I don't really see it, almost all of the "gotcha" cases he talked about aren't programming problems.
Earlier quoted context omitted.
> The programming parts of this would take 2-4 hours This is, literally, the error that the entire article works on dispelling. Anyone can write a rough command line tool that monitors the clipboard and prints to stdout. Writing a usable GUI application is a lot more work. That’s not project management, that’s coding work. The ratio of project management work to coding isn’t 10:1 or even 100:1 like you’re suggesting.
I could write it to properly log it to a user file, with reasonable default limits and take some of those as command line parameters etc, in a few hours. Running the program at start isn't programming, it is putting it in a "run on start" location, helping users do that is a part of managing the project and not programming. Figuring out what settings a user would want for it is also project management and not program…
- Tom Cargill, Bell Labs
Earlier quoted context omitted.
I could write it to properly log it to a user file, with reasonable default limits and take some of those as command line parameters etc, in a few hours. Running the program at start isn't programming, it is putting it in a "run on start" location, helping users do that is a part of managing the project and not programming. Figuring out what settings a user would want for it is also project management and not program…
But I didn’t give the students a programming problem. I gave them a software project to solve a problem I have, which involves UX and PM work along with some coding.
> A few students came to me asking if I had any ideas for a software project that they could work on outside of class. > I explained an idea for a utility that I had been wanting: A desktop program that monitors my clipboard for URLs and logs them automatically. I think this person misunderstood the students, the student wanted a project to practice programming, not a project to practice project management. The progr…
> The programming parts of this would take 2-4 hours This is, literally, the error that the entire article works on dispelling. Anyone can write a rough command line tool that monitors the clipboard and prints to stdout. Writing a usable GUI application is a lot more work. That’s not project management, that’s coding work. The ratio of project management work to coding isn’t 10:1 or even 100:1 like you’re suggesting.
tail -f /var/some-log-from-a-clipboard-daemon | grep big-tld-regex
Earlier quoted context omitted.
> The programming parts of this would take 2-4 hours This is, literally, the error that the entire article works on dispelling. Anyone can write a rough command line tool that monitors the clipboard and prints to stdout. Writing a usable GUI application is a lot more work. That’s not project management, that’s coding work. The ratio of project management work to coding isn’t 10:1 or even 100:1 like you’re suggesting.
I could write it to properly log it to a user file, with reasonable default limits and take some of those as command line parameters etc, in a few hours. Running the program at start isn't programming, it is putting it in a "run on start" location, helping users do that is a part of managing the project and not programming. Figuring out what settings a user would want for it is also project management and not program…
I'm confused by this. Any program that doesn't automatically set up this 'autostart' capability in an OS/architecture independent manner is much more of scriptkiddie solution than a real program.
If a program isn't made to run on any OS and any architecture without a multistep instruction set, it isn't really useful to many people at all. (And if your solution to this is Docker, re evaluate if you want anyone other than a handful of devs to use it)