“This project will only take 2 hours”
web.eecs.utk.edu
web.eecs.utk.edu
We had a bunch of .xml files containing some data, and someone wanted a .csv file... sure, an hour max, and it's done. Fire up some perl, loop, xml->hash, take the data needed, print line by line, done... less than an hour.
"Hey, can you add just this and that, and separate folders for this and a total and rolling sum?"
...yeah sure... hour or two.
"and this and that?"
...sure, another hour...
"Can this be made for that department to use.. just add a simple gui"
...and we've gone from an hour or two, to weeks or months of work. Nobody wanted a gui application made for "normal users", with all the checks and verifications and documentation and everything when you made a request... the scope was a simple one-off script, and that actually took an hour or two. This is like requesting a bicycle, than wanting to add a hitch for a boat trailer and making it higway-legal. And the added problem is, that your script never intended to do "all of this", and you either have to rewrite it from scratch, or you software looks like "the Burrow" (from harry potter).
Meanwhile, on an Apple or Windows computer it can be literally just plug and print.
The difference is that hiding those arcane input parameters takes work, and a lot of it. There was a quote that it takes 10x as much effort to remove an input parameter than simply leaving it in there and letting the user fill it out.
A lot of people don't get this, and think the simpler-looking software is simple, when under the hood it is probably doing model auto-detection, driver downloads, protocol negotiation, and even firmware updates on the fly!
I face this all the time at work. "Can't you just make a single button to run this task so I don't have to figure out how to use this complicated script?"
"I can, but not with this budget..."
Also: For some stuff I want to be able to use the "arcane" parameters for some really obscure task where it is just the right flag or something.
Moral of the story, printers are a necessary evil and what is wrong with the world.
EDIT: For future readers if you don't see the responses. The home printer was a Brother.
Also, this is not a statement that Linux is better. Think of it as the experience of using printers in general is pretty shitty regardless what your computer is running.
I wonder if in your case, your old printer relied on either 32-bit kernel extensions (I don't know if that's a thing), or if it relied on one of the deprecated Kernel Programming Interfaces such as IOUSBFamily. I also wonder if a printer driver falls into a category of deprecated extensions that are silently reported by the OS, because most do pop up an alert of some kind.
HP last year managed to accidentally revoke their macOS code signing certificate. I'm not sure how much software was affected, but as far as I know all HP software for Mac, including printer drivers, was broken (CRLs are updated automatically even if you have automatic software update disabled)
I remember this issue from a while back. Some update happened, and then wireless printing stopped working on some iOS devices. It happened to a colleague's macbook, and disabling IPv6 on the Brother printer fixed it for us. I can't remember where I found the initial advice, but here's someone else mentioning it: https://discussions.apple.com/thread/250584298
Any sufficiently large discussion of printers will beget a number of ad-hoc support sub-threads.
Nowadays the main advantage of Linux is that it won't install the manufacturer's driver. Anyway, the arcane settings aren't required anymore.
After sorting this out in the router, then add the printer to the various desktops/laptops/tablets/phones.
Maybe I'm imagining the improvement, but I don't think so (and it can't hurt).
One of the things I say often, too often, is, "Making it look easy is very very hard."
The problem was that the humans involved didn't really want what they asked for. They wanted control. They wanted to select a batch with certain characteristics, then another batch with others. They wanted to pass a list of files that must be included, a list that must not. They wanted audit functionality, they wanted multi-step selection, to mark files for auditing, translation, and different annotations types, to select a batch from one annotations type for another.
At the end of the day, this ever evolving script worked out very well and took away the need for a programmer doing complex sql and filesystem queries. There was still a human involved, but that was because the human wanted to be involved. The process taught me about users wanting something other than what they ask for, scope creep, and also showed me the value that could be generated via a fairly simple script created in collaboration with the user.
This week I discovered my Canon printer has some way to detect "plain [white] paper" and absolutely refuses to print on the high quality "cream" coloured paper instead. No matter what tricks I tried in swapping the paper, as soon as I put the better paper in the tray it would freak out.
I worked on an OS called CTOS back in the day. It was difficult to set up printing, because there was no feedback. It worked or it didn't, and there were queues to configure and services to install and network connections...
Somebody in a trade rag wrote "Its easy to print on an Apple, difficult on an IBM PC and impossible on CTOS". That smarted.
So a guy named Tom Ball (later the Java Swing guy) wrote a Prolog script that somehow could just tell you if printing was working or not, and what to do about it. Never figured out how he did that. BUt our trouble tickets went from something like 60% printer-related, to noise. Just like that.
I remember after all these years, and try to make software foolproof. For the customer service folk, because they matter.
I'm reminded of the first time I tried to get wifi going from a CLI-only NetBSD install. wpa_supplicant something something.. I eventually got it working but it was sort of a nightmare compared to how you connect wifi in an OS UI.
"Just" is a four-letter word and its use is forbidden. Replace it with "in addition" and change how everyone thinks about the request.
"It's just..." are the two words you never want to hear :)
I think all those people have the right to use your app.
There’s a point in drawing a line somewhere. But please, don’t make your app hard to use /on purpose/, not even with good intentions in mind.
And at work the "users" often have plenty of time. And even more, once they learn and automate half there job away. The world is not obliged to carry anyone along.
Indeed, they almost always do. Most users/stakeholders aren't good at technical specification of a solution that will meet their problem. It's part of our job to elucidate that in interaction with them.
And then, even when you are good at technical specification, sometimes it's hard even for domain-expert developers to fully understand the problem up front, without iterating. This is one of the useful observations attributed to "agile" (but of course not unique to it).
These are some of the reasons that projects often take longer than initially estimated, sure. You can complain about them, or complain about users being bad at specifying their problem/solution, but it's just a fact of reality, complaining about these facts won't make them go away, and part of doing a professional job is dealing with them.
Which means being very careful about assuming a feature/task is "easy", and remembering to do more investigation of the problem/domain/requirements than just taking a naive "easy" mission from stakeholders at face value -- which is what OP is about.
My exact case was some reporting for some project (15 people, 36 months, 1 xml per person per month), to throw into excell and draw one graph, for one PPT, a one time deal, for one project manager to show the numbers on the report.
The end project, if I didn't stop the idea, would be a black box, where you would put any number of random xmls, and get exactly what the accountant wanted with one button... so an impossible task.
What does the process look like when we ask back, "are you going to need to have a total and rolling sum? should we think about making a gui so other people can use it too?" Engaging the requests early on not only helps our planning, it helps the "client" figure that out sooner than later.
I think I've been successful in my career because I've been able to listen to a client's request and then help them figure out what they are actually asking for instead of taking it at face value. That can be easier said than done on an internal team, but it changes the quality of the product and dynamic of the team significantly.
The end project, if I didn't stop the idea, would be a black box, where you would put any number of random xmls, and get exactly what the accountant wanted with one button... so an impossible task.
> I think I've been successful in my career because I've been able to listen to a client's request and then help them figure out what they are actually asking for instead of taking it at face value. That can be easier said than done on an internal team, but it changes the quality of the product and dynamic of the team significantly.
Sometimes you can explore the actual scope by skillfully working with the client before you build anything. Sometimes, however, you can only learn what the actual requirement is by building the wrong thing first.
IMX, it's not even necessarily feature creep. It's failure to stop and adequately understand what constitutes a minimum viable product. Not viable to sell on the marketplace. Merely viable to deliver to another user.
There's a huge mistake in software development to think that the hard or complicated part is making the algorithm or understanding how your program will interact with it's own data or external data or hardware. That's seldom the actual hard part. The hard part is making it useful to a human being using the system.
If it's just for me, I can use a proof of concept that I wrote in perpetuity. I can deal with how janky it is or the obtuse error messages it spits out. If anybody else has to use it, though, there needs to be a mental model for interacting with the software that is intuitive and comprehensible to the user that doesn't require them to have a comprehensive understanding of the underlying code, clases, and interfaces.
This is the actual hard part of software development, and the bad part is that it's typically the part that nobody likes to do.
That's the lesson the professor is trying to teach here. It's not how to write a program. Nearly any fool can do that. The lesson is: how to author deliverable software.
this is the crux imo; an experienced engineer can hack together a compelling MVP of almost anything technical in a reasonable amount of time, but getting that same code in line with regulatory frameworks and the expectations of the end user is what separates a weekend script from a scalable business
"When a user takes a photo, the app should check whether they're in a national park..."
"Sure, easy GIS lookup. Gimme a few hours."
"... and check whether the photo is of a bird."
"I'll need a research team and five years."
> Here's a task that takes a day to do sloppily and at least two days for you to show your best work. We want to be respectful of your time so please don't spend more than 2 hours on it.
Point of programming assignment is to see if you can actually write code. No one is waiting for perfect implementation, just working code that fills the spec, documentation, and tests.
10 years ago, nearly no candidate pulled a distributed queue solution in a design interview and now it is a standard answer in their pocket.
However, there's always room for the interviewer to muck things up.
For the anagram problem, there are a range of solutions, including elegant & inefficient, clever & efficient, and robust & efficient. Do you dock someone depending on which they reach for first?
There's limited time, and a candidate may assume you're mostly interested in "how they think" and thus focus on the algorithm alone. After the interview, do you run the candidate's solution against test cases that you never mentioned, docking them for "missing" matters of casing or non-alphabetic characters? If the candidate themselves wrote unit tests, do you dock them for missing test cases you felt should have been included?
Do you dock them for not checking for invalid inputs, even though the candidate might normally work in a type checked variant of the language that wouldn't have permitted that anyway?
So many possible hidden assumptions. I know I've been rejected for similar unstated expectations in the past, and in retrospect, I know I've been guilty of doing the same to others.
This isn't a programming contest and your company isn't ACM
Just asking since it's a very easy task but I'd wanna doublecheck how to reverse a string in that language.
I received the task on Friday evening, I spent the week-end thinking about the problem. Monday I had actual work and on Tuesday, I spent a day coming up with a shit implementation. Then, I started improving it for two days until I think it got in a good shape. I basically wanted to transmit that I can start from the base, add functionality and then iterate on the problem by documenting, refactoring, adding tests, evolving the code base etc.
So I'd say I worked for around 24 hours over 168 hours and the feedback I got was:
> Thank you so much for your interest in joining <redacted> and the time you took to submit the coding challenge. In reviewing your application though, I have decided not to invite you to the next round of interviews as I believe there are other candidates that are a better fit for what <redacted> needs right now.
This is turning into a subjective rant, part of me wants to delete this but I'm just gonna go ahead and finish it; When I was younger, I used to love take-home assignments because it felt better than just doing algorithms, and then I used to get proper feedback, what I did wrong, what aspects I could improve in the future etc. This feedback gives me nothing. Just the realization I wasted time.
To this I'll add, I have a saying: "How you hire, is who you hire."
40 hrs? Waterfall? 2021?? And we all have been led to believe dinosaurs are extinct :)
I would never do take-home assignment again =))
I had a take home test that was to last 2 hours, and so I promised myself I would spend no longer on it. I provided a complete log of what I did minute by minute for a take home test for the last test I did as a defensive measure...
There was no break, no pondering, this was flat out knowing exactly what needed to be done and just typing constantly....
0:00 - started cloning
2:37 - finished cloning
3:11 - npm install
3:53 - localhost working
7:24 - removed timeout (intentional bug left in)
10:41 - Got images returned from the server (npm run serve)
13:27 - CSS started - thinking about design
22:26 - Grid for desktop
36:16 - Included user info
49:56 - responsive
56:37 - Added performance section
1:07 - Name form
1:21 - Email validation
1:35 - Most fields done. Need DOB
1:42 - DOB done
1:53 - form styling
1:57 - tidying up
2:01 - Saved this file
I didn't end up getting the job including feedback such as...
- Did not upload job search indicating repo to GitHub
- Didn't use `specific css attribute`
- Grid is rudimentary (the 11 minute one I made)
- HTML could be more semantic
- Form validation for name allows numbers (actually a programming falacy that names can technically be anything)
- Complaints about having multiple classes in one file.
I'm wondering exactly where I could have fit these in?
The week before I spent 4 hours on a task and delivered it within 12 hours of the assignment. I got an email with a single paragraph. `Unfortunately, after reviewing, the team has decided that they won't be moving forward to the next stage of the process with you`
These tests all have unrealistic expectations. I used to enjoy doing them for the learning experience, but now, it's just a solid graft with zero downtime coding the same app time after time.
So whenever I chat to a recruiter about the recruitment process I always drill down into the take home test, and the process of doing that let's them know that I won't be doing any take home tests. You have to simply question it sometimes and you can get it upgraded to a pair programming assignment which if you are honest, and have experience works in your favour.
I’ve withdrawn my application the last few times I’ve gotten task home assignments: I’d get to the 2 or 3 hour mark, realize I’m still working on clarifying my documentation (because I want to communicate that I consider this essential to a minimal product) and haven’t finished the feature(s) yet, call myself a shitty developer who is apparently an imposter, and then call it quits.
The key is lying because you already had a similar code base to use, most likely from interviewing so much you'd seen it before.
I was going to push as well, as I wanted to make sure that was set up right, but they associated that with 'pushing untested code to production'
but then they pretend its a meritocracy
It's also a great indication that it's not a company you want to work for anyway, but I don't have the stomach for accepting this level of disrespect towards applicants.
The only people who benefit from this situation are the people who have the luxury and freedom of 20 hours to spend on take-home projects. And even when I was that person once, I still hated it.
I’ve often wished I’d focussed more on coding over system administration but reading accounts like this makes me happier about my recent career choices.
Let's say there's two candidates for a position who are both asked to complete the take-home assignment, Candidate A and Candidate B.
Candidate A is the superior candidate and spends only two hours on the task (as requested), and Candidate B spends 2 days. Candidate B submits the better assignment and is more likely to land the job as a result, despite Candidate A being the better candidate.
Nothing complicated - shouldn't take too long.
Why not send people the assignment and ask them to return it within a couple of days? What are you gaining by limiting it to hours and turning it into a remote exam?
I suppose people's preferences vary a lot. Personally, I would turn this down. The format of "do as much work alone under pressure" is extremely offputting. I'd much rather do a whiteboard interview where the problem is well scoped in time and I can discuss my solution with the interviewers. I also wouldn't mind a take-home that actually takes 2 hours that I can do whenever I please - but asking for the work to be returned within hours is a dealbreaker for me.
If you are having time pressure challenges with our assignments we also don't want you.
But also if the person is so unwilling to co-operate that they can't so basic programming skill then I guess it wasn't meant to be.
For junior devs, we don't actually care if they do it in 2 hours, 2 days, or the whole 7 days we allow them. There's no bonus points for turning it in the next day, and I don't think anyone has ever actually done that.
But we're at the point that if they fail a single point in the requirements, we stop looking at them. This was a really hard decision, because there are candidates who are really nice and seem to otherwise do good work, but we've hired some of them and they inevitably continue to skip steps even in simple tickets. We end up letting them go after multiple warnings and months of wasted time, and having to do it all over again.
Of course, if you can't code you aren't going to get in either, but that actually seems to be a lower bar than following directions.
Kids in school often don't read assignments properly either, and skip everything until the first question. I don't know if they think it saves them time or fear there's a trick somewhere that they will avoid that way.
In life in general, people like ambiguity; it helps to smooth things out. But in programming it's a problem.
Like, if you expect me to write 1K lines of code in 2 hours as I read documentation, debug, test it - then god knows what the expectations are at a full day at work.
> 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 programming parts of this would take 2-4 hours, it isn't a terribly hard thing to code. All the project management parts would take days or weeks or even months or years depending on how polished you want it to be.
Giving them a project management project because in your mind project management is more important just to prove a point doesn't help them at all.
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.
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.
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.
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 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.
Most of UNIX literally seems to have been built like this.
> 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.)
People who write blog posts on the internet are not exactly immune to poor communication.
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)
This is a strawman, I never said these things aren't a part of a programmer's job.
> Nobody needs to go to college to become a hobbyist programmer
Nobody needs to do enterprise programming on hobby projects, you learn that on the job. For a hobby project it is more important that the project is fun, and very few find enterprise coding fun.
In some ways, school can be more insidious in its demands than enterprise.
Implementing every feature the Prof listed sounds like something I would only do for money.
Even professionally, there is still use for code that only ever gets run by its original author.
The enterprise programmer thinks nothing of deploying some J2EE monstrosity with "simple" setup scripts and "just change this Windows parameter in registry" and "run this command to create a service to start and stop from Services.msc". That's what they live and breath, that's the bar they are happy to clear.
The hobbyist enthusiast, on the other hand, will only have knowledge of actual consumer-grade software that "just works", so he will be at pains to make installation and execution simple and straightforward. He will take pride in every slick "just works" capability he can add, every tiny bit of OS integration he can squeeze, every line of setup-requirements documentation that can be removed.
One of the problems in the development of modern programming is that half the hobbyists are eventually horrified by the amount of effort it takes to develop on "modern" platforms and principles, and just give up; while the other half fall in love with such complexity, and happily proceed to add more, making the situation worse for the next generation. So development practices get harder and harder for no real reason.
I think it's even worse than that. I think that any time there is a widely adopted platform which is easy to customize without requiring any significant level of skill, there is some subset of people which churns out very simple tools to do popular things well enough, and stuffs those tools with adware / malware / spyware to make money. The platform vendor responds to this flood of crapware by adding new checks and processes to ensure software quality and security, and keeps doing so as long as quality and security is a problem. At a certain point, the platform in question is no longer the easiest target, and the people creating the crapware switch to the next platform, and the formerly-easy-to-deploy-to platform is now a complicated mess to write anything for.
tail -f /var/some-log-from-a-clipboard-daemon | grep big-tld-regex
I wouldn't even bother with the tld regex and just settle for "http"
The part I'm missing is what to tail?
while sleep .2 ; do xclip -o ; done | uniq | grep -E 'https?:'
I want to take this moment to remind you that the Web includes http, not just https, and ignoring it is a failure at accessibility and compatibility.
For myself a week from now looking for this, here is the version which works for me:
while true; do xclip -o | uniq | grep ^http > ~/url.txt ; sleep 5; done
You could probably do it very simply by remapping ctrl+c depending on your DE.
import pyperclip
import re
url_regex = re.compile('^(ftp|https?)')
while True:
text = pyperclip.waitForNewPaste()
if url_regex.match(text):
print(text)
... LOL.
There's a good chance that this will solve 95% of all needs. Most of the features suggested in the article beyond the original premise are unnecessary.
Not just the browser:
>links that I send to people across all the different messenger apps I have installed.
The article does say it might be useful to log where the URL was copied from, and potentially also where it is pasted to:
> I would also expect to know where the URL was copied from. I.e., whatever application is in focus when the clipboard is modified. It probably isn't feasible though to track everywhere it is pasted (maybe it is actually...).
E.g., is "foo.bar" a URL? Maybe. But it could also be a filename. How do you know if it's a "real" URL or not?
Schemes can be registered with IANA (or not), and everyone knows the most common half-dozen or so. People often forget "mailto:" and "tel:".
The project brief asks for one thing, but the practical implementation probably requires something else.
This is a good lesson to learn, and this is how two hours becomes two days, becomes two weeks.
> The term "Uniform Resource Locator" (URL) refers to the subset of URIs that [..] provide a means of locating the resource by describing its primary access mechanism
Since "foo.bar" does not describe an access mechanism, it is not a URL. Yes, you could make the argument that "foo.bar" is a relative-path reference as described in section 4.2, but that is only used to:
> express a URI reference relative to the name space of another hierarchical URI
So "foo.bar" can only be considered a URL in the context of another given URL, and in your example there is none.
[0] https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.3
Additionally, if foo.bar were a valid URL, then I would expect it to appear on the list. I can't read the user's mind as to whether the text should be treated as a URL or not.
The teacher is the client. The client is the one who will better estimate what is necessary or not.
If you own a company and someone wants to contract you for work, you start explaining how what the client says it needs is not necessary and how he can manage with less than he demands?
Sometimes, yes, it is necessary to coach a client. It takes trust, but it isn't unheard of.
Absolutely, you don't just build the first thing that the client asks for. And certainly not as a single main deliverable.
If you work in a consulting company, it is "good practice" to "convince" the client that he needs a lot more features so that you can sell him more man-days.
On the other hand, if you get payed a fixed price, incentives are turned around.
Incentives matter.
In different words: there are tens or hundreds of thousands of people who can describe software that would be very useful for them, but very few of those ideas would be profitable to fully develop.
Opportunity cost! Every stupid idea implemented snuffs out what could have been a good idea.
It may not turn out to be profitable for the client, but that's not my problem.
Of course nobody is going to come to a consultancy firm to ask for a command line utility that technically solves the problem. That's an entirely different situation you're describing.
Yes, it happens all of the time actually. Most clients don't come to you with clearly thought out solutions, they come with poorly articulated problems, and your job is to explore the problems they want to solve until they are well understood, and then devise a solution with the lowest cost.
Of those rare, rare clients that do know exactly what they need, they still have multiple constraints beyond those needs. For instance, budget. The client wants X within firm budget Y, X cannot be done within budget Y, therefore you make the case that either the budget must expand or they can make do with X' which only does 90% of X and that will fall within budget Y.
This is absurd. The students are the client. They asked the teacher for ideas for a hobby project. The teacher provided one, then followed up with a question about an estimate. Naturally, a student gave an estimate of how much time it would take to produce the product that they themselves were envisioning.
It’s not unreasonable for the teacher to point out additional features they might want to do, and how that affects such an estimate, but it IS unreasonable to call the original estimate “wrong.” It’s not wrong for a particular scope.
I’d have been incredibly disappointed to have a teacher like that.
As the saying goes: The 90% of the project takes 90% of the time. Remaining 10% takes 90% of the time.
It's a shame that Microsoft is shifting away from the old, reliable WinForms for their new UWP system because making a quick and dirty implementation of many or these requirements would actually take very little time for many moderately experienced C# GUI programmers. It'd be little more than a tray icon with a list view log, a settings screen and a crude search bar, but it sure would be functional.
I don't know any other GUI framework that would allow me personally to do this in the 2 hours as suggested, though. Even with other batteries-included toolkits like Electron (ew) would you need to do all kinds of special searches to get things like clipboard and setting sync working right. Maybe Python and Qt could serve a similar purpose, though you'd probably to pull in a lot of packages to get clipboard monitoring and database storage working right.
I get the point, which is that simple ideas often have hidden, complex requirements that take a lot more time, but in this circumstance it's really more a lesson about how bad the state of GUI programming still is after all these years. VB6, despite its stupid programming language, is still the golden standard for a GUI application design framework for me and we've barely made anything equally usable.
I think the reason is that many programmers have an urge to do things in a stupidly hard and complex way to look competent.
Real programmers do not use GUI drag and drop design tools.
Why shouldn't you design a GUI using a visual interface? Do you also write SVG's in notepad?
I was referring to the classic joke chain mail about 'real programmers' punching flip switches on mainframes or using FORTRAN, not Pascal.
1. download or use some screen recording software
2. Push record
3. Start coding
4. Upload your video to some site (youtube, etc.) when you're finished - or just live stream it.
I think you misunderstood the students. The person whose was actually present at the time the words were spoken says the students wanted ideas for a “software project”, not some extremely minimalistically defined “programming problem” It’s completely reasonable to assume they wanted to practice real world software development, not just how to implement the most pedantic set of requirements possible.
> It’s completely reasonable to assume they wanted to practice real world software development,
I've written real world command line utilities used by other programmers. It takes like an hour, I write the code and document how to use it in a readme, then if they have questions they just ask me. A lot of the time trying to do something complex big design up front kinda thing as suggested in this article is just a waste of time. Fiddling with UX on a project that will only ever get used by a few programmers is a waste of time.
This is one of those things that comes with experience. A junior programmer will make a meal of the simplest task. An experienced developer will, if possible, interpret the problem in a way that makes the implementation trivial while still solving the user's problem. Sometimes this doesn't actually involve writing any code at all.
I think any non-trivial task is going to surface technical limitations which might feed back into the stakeholder decision making process.
A junior might be alienated if they are outside that process, but if they approach it with a problem-solving mindset they'll likely have a more intimate knowledge of the closed loop.
Deliver version 1 before starting version 2.
Which, of course, is true 80-90% of the time.
Estimates are given as the following choices: hours, days, weeks, months, quarters. You never give a number tp the units. These all mean some "small number of X" where X is the list above. Then if Product has a question like, "Why would Z take weeks?" then you can have a discussion about the complexities and the task can be further refined and/or split into multiple things and those can be estimated as above, rinse and repeat.
That's my main problem with this advice and the article. Of course anyone wants a developer who can do both development and figure people out to bring out the most perfect estimates possible. But it's getting to a point developers are starting to be the solely responsible people on top of ever increasing technical requirements, while being given the minimum amount of practice figuring all this stuff out.
There’s a big medical structure. And in theory, there’s lots of folks to deal with XYZ. In practice, docs need to do YZ because they are the ones who have the right combination of training and authorization to complete the task. When more people get hired, the doc just has to communicate YZ to more people. Either the task requires nuance that is missed if you’re not the doc, or the task requires direct doc authorization at various points regardless. Doesn’t decrease their burden at all, even though there’s more people working on YZ.
Creating a game of telephone between the stakeholders and the people developing software is often going to impede communication.
The flip side of this is that a lot of technical people lack adequate soft skills to be able to do this requirements gathering well (probably the same can be said about a lot of doctors and what defines a "good" doctor).
One time, I had to estimate a UI migration. I made the estimate and added the disclaimer that the estimation assumed X was true and Y and Z were provided. Of course, X wasn't true, because the supplier sucked and Y and Z weren't provided by the business. So it ended up taking way more time than estimated.
Guess who got the blame anyway.
If that ever happens to you, don't wait around and suffer. Start looking for another job and save your sanity.
What people think they will want differs from what people will actually want which is not necessarily what data shows you should build. Build fast, improve incrementally.
The path highlighted in the article is exactly how you should not build a product. Don’t focus on all the things you could add, streamline your ideas as much as you can.
* stakeholders often need or think they need a whole estimate up front. A developer may explain MVPs, sprints, agile, etc. and still get blank stares and "ok, that sounds good, but just give us a rough estimate how long will it take/how much will it cost. We promise not to hold you to it (yeah right)". In some examples, like governmental budgeting, etc. it can be hard to even proceed through purchasing without a whole-product estimate.
* developers can be seen as over simplifying by stakeholders who don't understand the approach. When presented with a MVP, they start complaining about the fonts, etc. and loose faith in proceeding.
* developers can be seen as over complicating by stakeholders who don't understand the approach. When a stakeholder's simple request for "just an app to capture urls" balloons into a major project with bells and whistles over 10 weeks of dev cycles, management steps in and says "I thought this was just supposed to be a simple app to capture urls".
The later two come down to developers communicating effectively and stakeholders truly understanding their staff and processes. The first, I honestly haven't found a great fix for. No matter how I explain, many customers generally want an estimate and budget I stick to.
This took me ~10 minutes:
#!/bin/sh
set -e
while true; do
URLS="$(xsel | grep -Eo "(http|https)://[a-zA-Z0-9./?=_%:-]*")" &&
if [[ ! "${URLS}" = "${OLD_URLS}" ]]; then
echo "${URLS}" >> urls.txt
OLD_URLS="${URLS}"
fi
sleep 1
done;eg, copying http://example.com/foo and then http://example.com/bar and then http://example.com/baz I think urls.txt would look like:
http://example.com/foo
http://example.com/foo
http://example.com/bar
http://example.com/foo
http://example.com/bar
http://example.com/baz
One issue I did find when I ran it. The shebang should be:
#!/bin/bash
Want pause functionality: write a small utility to provide an easy way to start and kill any program.
Want notifications: write a program to monitor any file and provide notifications when something it added to it.
Searching: grep or a GUI equivalent
Syncing: rsync/syncthing/Dropbox…
Someone will complain most people can’t use these tools. Firstly that wasn’t the initial question, and secondly that’s something I’d love to see tackled in a GUI tool. I don’t think it’s impossible, just misaligned with the incentives of people who make and overcharge for proprietary software.
- Tom Cargill, Bell Labs
When we build a new city hall (under time and budget by the way), the actual building was finished after a year. It took another two years to make it useable as a city hall.
Why would software engineering be any different? The only real difference is that you have to do all the parts rather than specialising in brick laying, electrical stuff, plumbing and so on. Yes, this is really how little I know about construction and I still managed all the parts of the project concerning IT and networking (without really knowing anything about the instalment sides of that beyond the blueprint and trusting my operations guys either).
So maybe I’ve talked myself into agreeing with you, but perhaps not for the same reason. Because I wish it wasn’t true either, but mainly because I wish the software development industry wasn’t still so infantile that it still can’t predict and distribute the workload in a manner so that projects can be delivered under time and budget more often than not.
Some things are important to plan since they are hard to change, like user data or API boundaries, but other than that simple is usually the best to start with.
Was embarrassed by the quality, since it's just 5-6 snippets (of various style) pasted together...but I might as well share it anyway to prove the point: https://github.com/owenfi/clipboardcopies
The article does strike me as "scope creep" or missing the point of the question...I've taken this super crappy version and added it to my startup items, I think I might find it useful, and if I do it might grow over time. The polish can happen later if needed. I was able to accommodate a bit of the polish out of the gate by saving to individual files based on the time. The granularity roughly corresponds with the polling frequency. (Turns out there isn't a clipboard did change notification?)
To me the "complexities" are those things lurking beneath the surface, that a newbie doesn't know how to resolve, and an expert forgets to even point out. In this case the complexities I saw were: - Getting it to run required revoking and updating my provisioning certification (could've been solved another way I'm sure), this was fast because I've done it plenty of times in the past but things like this often throw up unnecessary roadblocks that aren't foreseen in the scope. (luckily I already had Xcode installed.) - Writing to the directory I wanted (~/.clipboards) proved futile due to sandboxing, and after 5-10 minutes I just gave up, since I want to consume this in terminal I can just cd into the app bundle documents area (or fix later). - How do you get git to merge up 2 repositories that were started independently (maybe I should've started from github in the first place, but I didn't think I would be saving or sharing it).
I'm not saying it's not worth thinking those things through or practicing project management...just that the first student was right.
The example just goes to show that if your original spec is incomplete, doesn't specify the quality, testing, and documentation requirements, and you pile up feature after feature (like cloud uploading), then it's going to take much longer. I'm sure the student knew that, however.
So when figuring out (for example) how to do X in language Y, I'm not very likely to stop at the first SO answer and call it done, because very often there's more to it (e.g. tradeoffs in performance, compatibility, composability, pitfalls & caveats, etc.). But the difference it makes in time taken can be massive. Maybe finding that first SO answer takes a minute, but gaining a deep understanding can take a few hours of reading and experimenting.
This ends up feeling weird for these take home assignments if you're using a new stack. My normal mode of operation is to gain deep understanding (and people generally consider me insightful, which I attribute to that pursuit of understanding), but this may look bad to someone who already knows the stack and/or thinks that you should just cope & paste.
Actually, I started this project in VBA after my partner insisted on it because he had those sheets with all the parameters for the model already in excel, and also a GUI he had created for the input. I accepted because I had taken a course on it @ uni, but soon felt the need for an easier way to program, and that's when I decided to go to Python.
Adding to this topic, now I can say it was easy enough, even for someone like me. A few times I needed help from actual people and got it from the kind and amazing folks that hang around StackOverflow Python chat, but mostly Python docs (or some simplified form of it provided by other website) and google queries would do the job when I had a code obstacle. Python was overall very intuitive for me, apart from a few surprises (mainly regarding scopes and names).
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.
That just reflects the size and complexity of stories they're asked to estimate.
Have you ever actually seen something like a planning poker session in action amongst only juniors? I have, and while this is very anecdotal, it has always played out like this: the most confident programmer in the group grossly underestimated the task. Often this person has a valid reason to be confident, but because of this, their opinion also weighs much more heavily in the group, so that even if someone throws the 100 card, the task will still end up with a 2.
The longer you work in the real world, the more you realise that estimates aren’t a showcase of you. They are timeline project managers need to implement projects, and if you fail to give a realistic estimate then you fuck with that timeline which is often the worst thing you can possibly do as a software developer.
Even if you “know” how to implement a really simple task, you simply need to make sure there is room for a days worth of searching for something really stupid, and you’re never going to be asked to estimate something really simple. Not as a junior, not as an experienced developer and not as a senior.
I do understand why students are taught to estimate wrongly though. Their projects aren’t very long. But I personally think we are doing them a huge disfavour by making them estimate in hours. Because why wouldn’t they expect that to be the norm if that’s what they’ve learned to do?
In any reasonably complex application even the smallest task will likely not be available to anyone in under a week anyway. Need to change a button? Sure, that's an hour or two to change it and ensure it didn't break some other scenario. Maybe that takes another day or so to verify with team X or dev Y in a PR. Wait for tests and processing for release to QA environment. Maybe another roundtrip if something is found, at which point you might be working on another button. Then it sits for a while until it can catch a production push.
I'm also assuming that the senior dev is working in a fairly large machine. If it's a startup then sure, anything goes depending on what shortcuts are in place.
In most of these cases, I actually suspect malice over ignorance. They figure they can squeeze some unpaid overtime out of an unsuspecting junior by pressuring them to "commit" to an unreasonable deadline and then trying to hold them to it.
There are certain brands of incompetence that get results, and you don't have to be the one that is aware of that fact to reap the rewards of manipulating people in that way.
The author defined project scope. Student discussed and came up with 4 hour estimate. Then after that estimate was made the author added a lot of requirements and said the student estimate was too low.
> The goal isn't to fall into a feature rabbit hole, but rather to understand your assumptions about the project. If I don't do this exercise and I try to build it, then I will often run into two or three crux issues that I could have easily known about from the start. Don't go implement every feature idea you come up with from this exercise!
I can see why this project will take longer than 2 hours if you introduce new requirements.
I have a bash alias that almost solves the problem as stated. I'm not on my PC at the moment, but it's something like (forgive formatting on mobile, space inserts keyboard suggestions so even this much indentation involves a bunch of copy-pasting).
while :; do
x="$(xclip -out)"
if [ "$x" != "$lastx" ]; then echo "$x"; fi
lastx="$x"
sleep 0.5
done
I don't disagree with the general point that some problems are deceptively hard and that, if you're making this for someone else (even this tech-savvy coding teacher), you'll probably spend an afternoon with polishing and extended testing included, and that gets longer the bigger the initial estimation (the famous one-weekend project). Still, a problem like replicating Twitter is probably a better example of something that seems very simple and the amount of time needed only becomes clear once you realize how much work it is to setup all the stuff around the core function of showing short messages to followers.
That turned out to have taken over a hundred hours of my time, and still counting. I started in June, expecting to finish by August. It's November now and I'm still at only 80%. There are just too many details that can't be predicted before starting to work on the specific part.
This happens at work too - "can you finish that feature now and release that in the next 15 mins or so"? Sorry, but I've only been a maintainer of this massive codebase for a few months, and haven't even touched that part of the program...? And yeah, I have other pressing work that I'm focusing on, so which one should wait?
“Why can’t I just do {x}, it would be easy to implement, any programmer could do it, why are {y company}’s developers so incompetent”.
Now I have a link to send them rather than awkwardly coming up with an example on the spot of why {x} is probably way more complicated than it seems, assuming you want it to actually work in any meaningful way.
They'll usually say something like "boil the kettle, pour the water in the cup and wait a few minutes"
So then you go in and probe all the requirements and edge cases:
- what if there's no water in the kettle?
- what if there's no power to the kettle?
- what if we're out of tea bags?
- how do I know when the kettle is boiled?
- can I put the tea bag in the cup while the kettle boils, or do I need to wait for the kettle to be ready first?
- what size cup do I need?
- how do I remove the tea bag?
- what if there are no clean spoons?
I noticed the 3rd column for quantity was "3 or more". I should have ran at that point. The next page of the spreadsheet added exceptions for certain item #'s, certain zip codes (each borough of NYC for example). It was still manageable but it was way past the two hour point.
Sadly, when this was originally put on the AS/400 it was 4,000 lines of IF statements since the original developer didn't put it in a database. It probably started out as a hack that said "for a quantity of 2, let's offer a discount on shipping", and then later someone said "If we're shipping to states on the west coast, use this price"...etc
Happened when I helped hire a friend to help with a trading project. This friend is simply one of the best coders out there, understands the domain, understands all the coding. The guy who was hiring him threw together a websocket, pulled some data, and thought there's just a tiny bit of work left in the details. He did it in nodejs.
Of course figuring out the details was the hard part, made especially hard by not having a clear request for what the project was going to do. Was perf important? What about all the various features?
It's really something to look out for as a manager. Don't be that guy who says everything is easy.
When your ear develops, you can hear that the real simple song is an outlier.
It's worse when combined with the "we say estimates aren't timeframes but secretly they are" problem: give a 3 day estimate for something, and when it's not finished in 3 calendar days (because only around 1/4 of that time was actually usable for work, the rest was pointless meetings or 20 minute gaps where nothing useful can be done), more meetings are scheduled to discuss why the estimates are "wrong".
I don't think it's a matter of trust. Management sees their job as setting priorities and resource allocation. So they shoehorn that into everything they touch. They require estimates, so they can divide impact by effort and then assign the highest ratios first, without regard to necessity or dependencies or technical debt.
So a 2hr assignment should generally take the interviewer about 40min max. And an interviewer should never hand out a question or task they themselves have not solved.
This rule is generally applicable in in-person interviews where candidates usually have 45m-1hr and are nervous and on-the-spot. The question should take the interviewer about 15 minutes, and don't forget to have time to talk through their solution and give time at the end for their questions.
And the last piece of interviewer advice for now: look for reasons to hire the person. Identify what would this person add to the team and company. It is easy to find flaws in everyone.
Anyway, tangential to the article but relevant enough to share I think.
But I have to respond: Or you could grab something similar and use that as a beginning point. Say, for this application, `clipman` which gives me a popup list of the last few clipboard entries. Get into that and add some regexp filter and log output and it need not even interfere with the original functionality.
One of the great ideas in open source is that others can use my software without me having a "maintenance burden" for their use. They can maintain their own copy if they like, depend on me, or decide shit don't work.
If I did my proposed hack i doubt I'd bother the upstream developers with it; if dozens of users like it, maybe later it could be made worthy of further public consideration. But "is the maintenance burden too high" as a consideration before you begin writing is a great excuse to never try.
Estimating effort is important. Work is an investment, so the decision to invest changes with the amount of work.
I think this lesson can only be learned the hard way: create a new application and try to get users. You’ll learn where you spend time and get better at estimating. You’ll also appreciate why “simple” features appear slowly in software you use.
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
Monitoring the clipboard periodically, determining if there's a URL, and recording it somewhere if it is - that's easy. If it's a student project to show that something can be done, then you are DONE.
If it's a tool that you hope others will actually use, then yes, you need more.
- 80/20. Yeah, much of it goes quicly. But the devil is in the details, and those add up, especially when you're staring into the abyss of an unknown.
- I learned this early on in my career. It applies to just about all projects, not only software.
"It'll take twice as long (and cost twice as much) as your original back of the envelope estimate."
I wish I had $20 for everytime I saw this come true. With that kinda money Bezos and Zuck would be working for me :)
I believe that schedule crunches aren't just management's fault. They are often exacerbated by engineers, not "playing the tape through," and giving unrealistic estimates, or agreeing to unrealistic estimates.
Just "notify the user"... imagine the amount of code and the number of APIs this needs to touch.
Software is way complex and devil is in the details.
... and producing the chart in the first place.
The important thing is that all of these automatically get synced and become searchable easily.
Good idea.
This is normal software development. PO/customer wants something. You give your estimate. They accept it and you start working and then middle of the sprint or in demo or during testing they come up with new requirements. These were not in the scope of the original project and thus need to be re-evaluated with new estimates and possibly new project.
Instead, he just explained to the students why it’s much more complicated than that, probably discouraged them from trying to build anything at all, and as a result is no closer to having any kind of way to capture the URLs he copy pasted during the day. No value was created in this exchange.
My overall reaction to this is this feels very much like an academic approach untethered to what kind of practices actually work for creating products in industry, and instead is working to inculcate students in bad habits that will turn them into the kind of developer who, when asked to solve a problem, comes up with a long list of reasons why it’s too much effort to be worthwhile, rather than a list of ways to figure out how to solve the problem.
In particular, this pattern of listing ‘but have you thought about…’ questions is amateurish product owner BS and it does students a disservice to suggest this qualifies as any kind of requirement analysis model, let alone a first step in deciding how to go about building a piece of software. It is a great way to stop yourself from even starting.
Requirements gathering doesn’t consist of guessing what things a user might want, or even asking a user what they think they want. Yet the professor goes off positing a need for a pause mode, timestamps recording next to URLs, log encryption… all of which are maybe interesting but none of them seem like they make or break the viability of the product.
On the other hand, if it turns out you can’t actually make a program that has sufficient permissions to read arbitrary clipboard contents without triggering a malware detector or getting blocked from installation on a university computer, that would rather screw with the entire project, so maybe focus on verifying that you can at least do that first before you start wondering about what color the system tray icon is going to be.
And maybe your research will turn up some interesting affordances or edge cases in the clipboard API that you hadn’t thought of that take the project in a completely different direction?
The fact one of the students said something important that identified a key risk to the entire project concept: ‘I’ve never interacted with the clipboard api before’ - and then that got glossed over for discussion of all the shiny affordances that could be bolted on to the solution - was a real miss of a teachable moment.
The professor gave the students incomplete information. What they said is perfectly reasonable. This is a project they will be doing on their own time, so the scope of it is entirely up to them.
All that’s left is compiling a deps list of react components.
English is far more verbose than machine languages. It can easily make a problem seem like there’s a lot more to consider than there is if you’ve already got a corpus of syntax to leverage.