Comment by skytreader | Hacker News Reader

Comment by skytreader | Hacker News Reader

Parent Full thread

I'm sorry but I gotta call this out; this is just peak HN arrogance. All we have is an article relating an anecdote and the reaction to it is to second-guess the author's actions/interpretation of events. Surely, the author has more context of what was actually happening, what was actually being asked for?

The actual words used were already vague enough ("ideas for a software project"). The answer to that would always be subjective. Why is there no trust in the author that he has a better read of the room? He definitely has more context of what the students were actually asking for. These are also, students; I'd give the author benefit of the doubt that he gave them a problem that would be most productive use of their time given their skill level. Maybe that's why he didn't consider web browsers or bug trackers.

FWIW, I think the article makes a good point but is poorly illustrated, especially for this audience. I've no doubt your average HN commenter has projects/scripts under their belt more complicated than a clipboard logger, maybe even on far tighter time constraints. But c'mon, these are students! If you work in the industry there will definitely be different causes for project under-estimation.

But the author gave a project idea where most of the project was figuring out UX concerns of non existing users. It is a horrible project no matter how you view it. If you do UX then you need users to actually test what you write on. If you don't do UX then this project is very easy. Sure these students might not have done it in 4 hours, but not because they would get stuck on whatever the author talked about, but because they would try to look up API documentation for whatever OS they work with or bugs in their URL detection code.

And since the author teaches software engineering classes and not UX classes I assume this would be a software engineering project and not a UX project. Building out a lot of UX features without users is an anti pattern, better write a bare bones implementation first (start from command line, help first users set it up and see how they like it) and then work from there. For a hobby project that would likely be the end of the project, and a good student could get it in a few hours I'm sure.

I think I have to agree about the "peak HN arrogance" bit

Most things about software dev are never taught to college students. This is actually an excellent project to teach students beyond programming for computers and building things for humans. Not thinking about UX is what leads to most software projects failing because we are fundamentally different from computers (do I even need to explain this?)

I wish I had teachers teaching me stuff like this in my software dev classes instead of the usual stuff. I wouldn't have had to waste years trying and failing to learn this

> I wish I had teachers teaching me stuff like this in my software dev classes instead of the usual stuff.

I think this would be a great class project with the teacher acting as a fictive user. I think it is a horrible hobby project to suggest.

This situation says a lot about attitudes to development in general. "It's just a hobby project, who cares?" is fine until it's useful enough to end up in production code without being production quality.

Most of UNIX literally seems to have been built like this.

> But the author gave a project idea where most of the project was figuring out UX concerns of non existing users.

> If you do UX then you need users to actually test what you write on.

No offense to azhenley but why do you expect any different? They asked a CS professor for a project idea. How many CS professors have project ideas that come with UX case-studies? How many CS professors have the resources to guide students to coordinate actual UX tests outside of a research grant?

It's an outside-of-class project. It doesn't need a compelling use-case.

> It is a horrible project no matter how you view it.

Too harsh, this has yet pedagogical value. Because, you know, they are students. Bulk (if not all) of the work you typically do at school teaches you things even if they are not portfolio-worthy.

> Building out a lot of UX features without users is an anti pattern, better write a bare bones implementation first and then work from there.

I agree with the thought but, again, this isn't real-world software engineering. I feel I can't emphasize this enough. Maybe these students have been writing from-stdlib-up CLI tools ever since and their teacher thought it's time to expose them to APIs other than stdlib. Who knows.

Might as well raise pitchforks that finding the most valuable customer for Northwind Traders (LLC) is counter-productive because the database is outdated. Better gather data first, why not normalize the schema while you are at it, so you can stream it to the cloud and get a better analysis than plain SQL. (Calm down, Northwind is a sample database for education purposes.)

Yeah, I think I kind of lost the thread after a few levels here. The original point was that the student estimate wasn't that wrong for a hobby definition of getting a project done.

The content of the anecdote related implies a disconnect between what the students' and the authors' understanding of the situation. This seems like pretty good reason to believe that the author was plausibly wrong about what (at least some of) the students were asking for.

People who write blog posts on the internet are not exactly immune to poor communication.

Reply on news.ycombinator.com