> I also take a lot of photographs, and I could use a tagging scheme that isn't tied to a do-everything program like Adobe Lightroom. That's simple enough that I could create a minimal solution in an afternoon.
Having done exactly that (tagging and collating app for images), I can report that it is likely to take somewhat longer than “an afternoon.”
The Programmer’s Credo:
We do what we do; not because it is easy, but because we thought it would be easy.
What the xkcd chart misses is that if you can get a hundred people to use your code, the payback curve is a lot more forgiving. Parr only needs 366 customers for the universe to balance out, and that’s only if you didn’t grow as a person as part of doing that work.
I don’t do volunteer work for myself. I do, but also I don’t.
Years ago when Microsoft canceled its WinFS project, I began building the kind of file system that I wanted. Like other file systems, it had to be able to store hundreds of millions (or billions) of files and keep track of all their data streams even when they became highly fragmented.
After just a few months, I had a base system that seemed to work pretty well. Then I wanted to be able to define meta-data tags and attach values easily to each of the files, then find all the files that had certain tags attached very quickly. This part took more time, but I had that working within the first year.
Since then, I have worked years on adding new features to the project (https://didgets.com/) as each new idea comes to me. It now does database, logging, indexing, and other tasks well. For every task I pull off the 'TODO' pile and get it working, I seem to add two new items to the list.
I never thought it would be easy, but it has been even harder than I originally thought. But I love to program and enjoy getting an idea to work in code so I stick with it.
Is there much, if any, platform specific code in there? It seems like the GUI is based on Qt5 already, which is cross-platform.
Also do you have a commercial Qt5 license? I think some components, like QtCharts, are "commercial or GPLv3", so you need to be careful with redistributing. IANAL but not having a license would mean the GPL now dictates you should release your entire program as GPLv3, which I assume is not what you want, as the source code is not available anywhere.
There is just a single module (couple hundred lines of code) that is platform specific. This can be easily ported to Linux and/or MacOS. I had a Linux version running for awhile, but just don't have the resources yet to support multiple platforms for every build.
There are two separate pieces of the project. The 'Engine' code does all the real work of managing the data and executing the queries. The 'Browser App' is used as an Admin/Demo tool which uses the Qt windowing platform. The browser just calls the engine API and makes the data display nicely in the various windows and dialogs.
I will probably open-source the browser code. I am still trying to figure out if and when I will release the engine code using one of the open source licenses. It really depends on if it can get some traction so that it is worth the effort.
I’ve come to appreciate that the last ~20% of the work takes 80% of the time and if I adjust my expectations I can usually get an 80% solution in 20% of the time.
If you cut with the grain you can get a surprising amount done in a short amount of time.
Depending on the project, I have a bunch of personal 80% projects that I’m happy with where they are.
I could add native language support for other wikis (some people have forked the project and done just that), but it would be that 20% work. I could expand my coverage beyond the “top articles” but it exceeds what I can track in git so I’d either have to use Wikipedia’s API (slow and offloads cost to Wikipedia) or roll my own DB backend. That’s part of the last 20%. I could update the repo to keep it “fresh” but I’d exceed the git object limit on GitHub and have to have some amount of long-running cron based automation. I choose to leave it as is.
I could store previously discovered albums, but I’d need a DB. I could return more than one album at a time, but I’d have to deal with rate limits and cache responses to take load off Deezer. These are all part of that last 20%, so I leave it with one recommendation per page load.
For things I plan to monetize or share with others I tread out into that 20%. Like https://persona.ink
For my customer contracts I share the same options with them. I let them know when we are cutting against the grain and where costs are going to balloon. I give them options to reduce cost by adjusting their expectations. I’m happy to charge them for the work, but I’d like to give them the chance to save on my time if they can live with the compromises.
Good advice to advance your career, but I'd say there's nothing wrong with being passionate/excited about the craft and not the result. Newbies should just be aware that this can affect their career (they will have better job security as they won't be picky about the domain, but they will probably earn less as they won't ever be domain experts).
There are endless examples from other "industries".
There are people that love painting, but never care who sees their work. They love the creative process.
There are people that love carpentry, but hate doing utilitarian furniture that sells well. They love how zen manual labor can be and that the result is physical.
It's not "wrong-way-aroundness", it's just a different goal.
Well said. I spend my day doing professional software development in a particular domain, where I solve real, tangible problems. In the evening I like to spend some time on aimless programming, tinkering with new languages, technologies, tools, etc. I do it for the enjoyment of the learning and the creative process as you mentioned, with no particular goal in mind.
> but they will probably earn less as they won't ever be domain experts
I disagree.
I've rarely seen any programmers that are domain experts, most of those domain experts are actually hired in a consultancy role.
As they work through the projects programmers can become very familiar to a specific domain but in general that's not their job and they will be treated as such. They will be consulted on implementation but less likely, if at all, on strategy. Which is what I would expect from a domain expert i.e. a consultant.
The highest paid programmers move jobs most often the lowest paid don't that'll tell you what becoming a domain expert means for a programmer.
While it's true that in practice most programmers are bricklayers (especially given the growth of the industry leading to a young-skewing population), that doesn't invalidate the GP's thesis that domain expertise is a good lever for compensation growth. The biggest mistakes and greatest successes of my programming career have always been related to the breadth of my understanding of the product domain and UX that I was operating in.
The other thing I find curious in your comment is the implication that strategy is usually set by domain experts who tend to be consultants. This very much runs counter to my experience, where consultants are brought in for specific jobs or problems where an outside perspective is needed, but generally those things are scope-boxed or time-boxed tangents to the business. The big strategy is generally set by leaders and influencers within the company via a mix of formal and informal venues. These individuals will have the most knowledge of the context specific to that business and how it competes in the marketplace. Consultants, by contrast, can develop a cross-cutting knowledge of industry, which can be a valuable data point well worth paying for, but a company who relies on consultants as the primary driver of strategy is rudderless and probably in decline.
You are probably thinking of management or business consultants like McKinsey and the like. A lot of companies will hire a consultant as a permanent member of staff when they are working in a specialist domain note they may be called something different like solution architect or suchlike but they are acting as consultant.
I've been in several that had these types. I think the only companies that didn't were companies in industries that didn't need any specific domain experience example here are one that did:
* Oil and Gas (Flow metering)
* Network Timing and Sync testing
* Health and Care (Worked in Care and had several)
I disagree, imagine if someone showed up to a construction site and said "I bought a new hammer and have little to no idea how to use it, are there any cool or important projects I can pound nails into?"
If it was my home, I would hope the crew boss would tell them to go build a shed or something first.
In this scenario he'd just be told exactly which nails to pound and his work would be inspected.
This is a very good example actually, construction work is a really popular summer gig for students in my country (Poland). They know nothing and don't care about the domain (building houses), they just follow supervisors and the designs.
You can't give them an entire house to build, but they are very useful and cheap members of the crew.
They'll never be architects (they don't want to), but they'll earn enough to buy whatever students want and they'll always find some work no matter what is being built and where.
I worked construction in high school and college in the US. This is not how it generally works. If you are a high school kid, your summer construction gig is usually slave labor, meaning carrying ton of stuff up and down, cleaning stuff as you go and be a general gopher. You don't do anything remotely close to the construction of the house. The only exception is being a roofer, which you just tar stuff with other crew members.
I think that's a bit outside of the topic, because we're now discussing a case of "only passion, 0 knowledge" which was not the point.
The author of the article thinks that not looking at the bigger picture (or the upper "decision level" if you will) is inherently wrong.
My point is that enjoying the process and not caring about the product is more than enough realistically.
So assume a worker that perfectly knows and likes their job, but doesn't care about the process "above" him.
If you enjoy the process of tiling and you have some experience with tiling, you don't have to care about what kind of building/room you are working on.
Somebody designed the room, somebody picked the right materials, somebody probably bought them and it's in the spec/design. You can just "tile away" and make a career out of it.
Similarly in software, if you care only about programming and languages and whatnot and not the product - it's all you need with the right team/org. You won't be a product owner and you wont advance to "decision-making" levels in the company, but if you don't want to why would you need to.
I can't really agree to what you are describing, despite the fact that certain parts of my career, I fit your description perfectly.
The issue I have with is the statement of "make a career out of it". I don't think you can, at least not in the software industry, a lot of folks are perfectly competent developers but can't move forward and eventually get replaced by younger/cheaper developers because they are basically doing the same thing for the past 10 years.
I agree with having passions for something, but making a career out of it is a lot harder if you don't do the "extra".
> a lot of folks are perfectly competent developers but can't move forward and eventually get replaced by younger/cheaper developers because they are basically doing the same thing for the past 10 years
I'd argue that they are replaced (if they are, because I'm not sure, there are not a lot of old folk because IT industry is pretty young, I already worked with a few 50+ mid devs and the pay is kinda reverse, because old folk already have homes and don't need to pay off huge mortgages) not because they didn't get promoted (mid dev -> product owner / domain expert) but because they stopped upgrading the skills relevant to their current job.
So in terms of the example presented by the author it would be developers that are no longer even hyped about languages/tools.
And in our imaginary "tiling specialist" it would be a guy that didn't care that the current fad is some kind of funky pattern + new material of tiles and still wanted to lay old ceramic square tiles for his entire life.
I'm still not convinced that there is a scenario where you __have to__ care about "the domain" / "the problem being solved" / "the bigger picture" that much. You can, it will improve some aspects of your career, but you don't have to and it would degrade other aspects of said career (we all have about 16h max productive hours daily, and I'm being generous).
There isnt anything stopping you from asking questions like why is something done this way. You might see it as slave labour, but if you laid bricks for example, you cant lay bricks in temperatures below 3 or 4 degrees C, and you can only lay so many rows of bricks high as the mortar has to set.
Where most people are failed by those around them, like parents and school's is pointing out when you leave education, you wont stop learning, and its always good to ask questions and plan ahead what you want to do with your life.
Arguably have a bucket list which will change as you age in order to have something to aim for, and dont get caught in the trap of settling for second best or end up being used by people who think might be your friends but only knew you because of what you could do for them on the cheap.
Now you might have called your summer job slave labour, I look at it as being paid to exercise as well as learning new skills and make new contacts.
On the subject of aimless excited programmers, there's lots of ways to look at programming before learning a language.
If one wants to earn a lot of money, then consider database related programming, everything is data, even spreadsheets can be considered flat files of sorts.
And whilst you probably wouldnt use javascript to write a database app in, even though you could stuff data into a cookie and run it client side, there are better general purpose languages suited to database work, besides the obvious sql languages.
If chasing the money, consider looking at what's involved in high frequency trading where you'll be writing your own OS to maintain the super high speeds required for algorithmic trading. Co-locating data centres as close as possible to trading exchanges is just one part of the problem. [1]
IF you want to do apps for smart phones, again look at the languages that deliver the most for you, but also consider whether you should go with a popular language like dotnet or java thats portable across platforms, or whether you want to go with a niche language that might become less popular over time especially when considering there are thousands of languages that exist, with many having fallen by the wayside.
In other words, the supervisor holds the vision of the output, and that person assures that the people interested in the craft are acting towards creating the desired output.
That sounds a bit out of place in a construction site, but every mechanical shop has something to try the new hammer on, and the equivalent in a physics lab would stop everybody so they bring stuff to try the hammer on.
The difference is mostly of culture, and seems completely irrelevant to what you are trying to say.
There are 2 things that excite human -- learning and realisation. The author pointed out the way how to realise a thing.
But as many are also saying, being aimless is an opportunity to learn, explore and discover new possibilities. It's like how many of us are playing with ChatGPT at the moment. It's a journey of discovery that can lead you to realise the potential and create something truly amazing in later time. Would anyone say porting ChatGPT to many existing applications aimless?
Yeah, exactly. What if there're no problems to solve? I like the metronome just fine and I want to write a Tetris in Haskell just to see if I can do it, or something like that?
Even if someone created a design that solves "the problem", there are probably thousands of subjects/situations where that design needs to be actually applied.
No single software scales infinitely and is infinitely customizable. Some software even is customizable too much and that becomes its own problem.
We need a lot of "bricklayers" that don't care about the problem but can be elastically moved around between projects to implement the ever increasing backlog of "solutions". Entire companies are created that solve that exact problem.
This is the old Joseph Weizenbaum observation that the computer is a "solution looking for a problem," which, now that you mention it, I think can be applied to the entire tech industry.
I noticed that whenever something like this gets posted (in a nutshell: the advice is to be practical in what you work on) - a common response is that not everything must have utility, you can enjoy things just for their own sake.
This is true, but the reason this is advice (ie, suggestions of the best course of action) is that if you can get your enjoyment to line up with what's useful, your life gets better than if you keep it separate.
Like, if you hate your job and come home to work on something fun but impractical, you still hate your job where you spend most of your day. If you can "tune" your mind to enjoy something practical, potentially that thing can grow and you can do it full time (ie also enjoy your job)
Another example is people who taught themselves to love working out or studying. They win twice - from doing something they enjoy and from engaging in something that bears fruit for themselves.
I noticed those comments as well and would make a slightly different point, which is that part of the reason it is good advice is that having a practical goal can be both motivating and directly helpful in the learning process. Motivating because you are more likely to finish a project that you want to use the result of. Directly helpful because it's easier to learn something when you see its utility at work.
Another way to say this: To develop in short cycles, you have to interact frequently with the actual user of the program. The simplest solution to this is to choose a program where the developer is also the user.
I like this framing. It's not that aimless, excited newbies can ONLY make small things for their own use. It's just that doing so makes an important and easy-to-mess-up part of the process (i.e. collecting and synthesizing end user requirements and feedback) nearly automatic. But framing it this way suggests a natural progression to eventually making things for other people too.
Also the commonest? Like half the startups I see do this and no wonder they fail, there’s only so many tools you can make for devs and make a lot of money.
I do think it overlooks the idea that some people enjoy the process of programming, while others enjoy the solved problem. If I do a crossword puzzle or Sudoku, I don't frame it, don't care, I enjoyed doing it.
Now one of his points is that a program by someone who does not use it that enjoys creating it will be inferior to someone who uses it and wants the solution.
This is true, sometimes, but other times, what happens is the solution is over fitted to the person who wants it.
Also, often software that is clunky because the person is not interested in the result, yes, but it is better than software that does not exist.
> Would you trust a music notation program developed by a non-musician? A Photoshop clone written by someone who has never used Photoshop professionally?
Wouldn't a fresh look at things, essentially a "clean room" implementation offer the possibility of a novel approach to a thing or two, as opposed to making the same tool, just different?
But overall the idea of matching one's ambitions (project scope) to one's abilities (including domain knowledge) is a good one.
Not doing that is why we get things like Kickstarter campaigns for MMO games by novice developers, which never go anywhere as projects. Of course, it's also useful to fail and be humbled with learning projects, especially when someone's money is NOT on the line. Maybe more people should explore developing something like microservices in non-prod projects to better learn their advantages and disadvantages and so on.
I think a lot of it is hubris; they've solved some things in domains they weren't familiar with, so they think they can do it again. I mean some hubris is fine, but "I will change the world with this" is probably a bit misguided in a lot of situations.
I mean working as a consultant I've worked in industries like public transit, finance, energy, postal etc, but nowhere did I think I understood enough to fix the whole thing. Actually working in those industries makes you appreciate the scale and scope of them, and that unless you end up at C-level, anything you do will probably only affect a small aspect of the whole construction.
And that's just fine, do what you can and you'll make it to retirement, take on more than you can chew and you'll end up overworked, disillusioned, or fired.
Not sure how you define "musician". There is a person who has gone to school as a musician, who works professionally, or who teaches music in school (an elementary school music teacher has a remarkable breadth of skill and knowledge.) Then there's the person who taught themselves to pick at a guitar who could be a rather serious amateur. (Myself I'd say I'm not because after trying to get better at singing I decided to sing off key because people seemed to be more entertained by it.)
If an amateur was interested enough in music to make a music notation program I'd say they're a serious amateur who has every right to try it.
I'm not too stringent with any concrete definitions here, but one of the things that came to mind when considering that possibility of a fresh look was Sonic Pi, which lets you code music: https://www.youtube.com/watch?v=suH_goWVBeA
I'm fairly certain that it's quite different, when compared to decades if not centuries of past methods, all thanks to someone with a particular set of software development skills taking a new look at the already existing approaches and deciding to do something different.
It looks also like something that won't be used by anyone who is familiar with the existing approaches, generally happy with them and is just looking for tools that would help them with what they are already doing. The nice part is that nobody's trying to push it as a replacement for existing notation programs or DAWs.
> Wouldn't a fresh look at things, essentially a "clean room" implementation offer the possibility of a novel approach to a thing or two, as opposed to making the same tool, just different?
Yes, sometimes, but if that’s what you’re going for it’s still important that you’re solving a problem that you understand well. So maybe I would be okay with someone with limited photoshop experience making an image editor, but I hope they still have a designer/artist/etc. background.
> Yes, sometimes, but if that’s what you’re going for it’s still important that you’re solving a problem that you understand well.
I disagree. Writing a program can be a fantastic way to learn more about the problem. Of course, if you want the program to be good, you’ll probably end up needing to do some serious iteration/rewriting as you learn more.
Just look into a some nearly arbitrary industry/department where Excel is used extensively. Replacing some "cobbled together" Excel workbooks with properly implemented applications very often yields a lot of low-hanging fruits where you can "add value with code".
How would you get people to trust you to do this and make a solution that they can maintain in the long term? It's hard for me to envision an organization accepting this offer.
I know people for whom what I described is the daily job.
Of course, the respective organization has to ensure that there do exist programmers who can maintain the software (but having to maintain it or adding new features from time to time is typically a lot less work than writing the original software from scratch).
I usually make workflows fully automated or save so much time that people just don't want to go back.
If I cannot automate the full workflow I try to get to a solution that saves as much resources as possible without actually needing the "solution" to do it. It just saves resources
I think this is a good approach & you can definitely write small programmes that solve low hanging fruit for others rather than yourself.
The trouble the hypothetical dev in the article has is that they're searching in the wrong place — the 'solution domain' (Rust mailing list) rather than the problem domain.
I think if you want good project ideas, go to any random problem domain e.g. find a woodworkers mailing list, say & ask — "what small little programme could I write that would help you when starting projects".
Then, because you've just learned Rust, programme it in Rust. But the people you're developing it for neither need to know or care what language it's in.
If you go to the Rust mailing list to ask for project ideas then you're going to either get non-real-world sample projects (build a calculator), or you're likely to get something that's a problem for Rust devs, which is likely over your head as a beginner.
I believe there is a way to accomplish this without seeking input from people on Reddit or message boards for new domains to contribute to.
There are lists on Github that curate libraries native to a particular programming language. For example, there is a list for Lua (https://github.com/LewisJEllis/awesome-lua) and another for Python (https://github.com/vinta/awesome-python). Explore these lists to identify areas that may require assistance. Some of these lists have not been updated for years, so it is worthwhile to conduct additional research on the domain before undertaking a project.
I have personally completed a project using this approach, although I did have some background knowledge in that domain.
I somehow get paid to be an aimless and excited programmer. I work in developer relations for a data company. Even though my title says, "engineer", I don't do product building.
I don't have any exact direction honestly. We have a data product and I do random things as long as it improves the developer experience.
One month I am writing a technical blog for beginners on using the API using Csharp, before that it was writing a 15 page technical document on Snowflake, yesterday I made some demo GIFs using a CSVgrep for a product launch.
It is chaotic and I really don't have an exact year-long focus when it comes to programming commitment. The only thing that is true is that the API/database we provide, which is being used by real programmers from different backgrounds. The DevRel role demands someone to be aimless and excited. You have to know enough about developers to help them get started, but you are not required to carry them to the finish line.
"Being aimless and always excited" as personality trait largely helps me to do a great a job. I do have to report to my manager, and I am a part of a team, so, I have to maintain a framework.
Although time to time, I suffer from being too aimless and too excited, and like a golden retriever I have to be told to calm down. Sometimes I have to remind myself it is a job.
Kind of same really. For the past 8 years I've been just "a senior developer".
Commercially I've created some CRUD document-processing systems with .NET + web stuff, I've created some apps for smart barcode scanners for warehouses, I've done some touch-only "pretty" apps for corporate reception desks, I've done some mobile apps based on GPS-tracking and QR-sharing, I've done some database-only solutions too (SSIS-based migrations between systems) and many more (desktops, games even).
In my private time I'm having fun with procedural graphics and game-like apps.
Can't say that I'm a domain expert in any of these, but I'm in top 1% earning bracket in Poland (mostly because the general pay in PL is shit and IT is one of the few jobs with "globalized" salary) and that's all I need in life.
This approach also has some not often discussed advantages. Like I don't ever worry about job security as there's hundreds of those "CRUD"-making companies all over the world. I've actually went full contractor mode (not paid by the hour, but by completing "specs" (sometimes modules, sometimes entire projects)) in 2019 and I'm booked fully this year (signed contracts by both sides) :V
I label myself as a "Python Developer" and have no high-level expertise over any specific domain of programming.
This experience doesn't translate well to organizational software engineering where there is structure and hierarchy. I like solving problems programmatically period. Organizations want people to solve very specific problems very specifically. I wasn't able to be that person. That made freelancing and doing contract work the only option for me.
However, I just don't enjoy contract work. There are just too many unpredictable variables and not all clients are the same. So, I am very lucky have my full-time job.
I have a solid grasp on our product and am familiar with the programming side. I try my best to be the first person to answer any business side queries about our product. Our startup-esque nature enables me to have this freedom and excitement. But I do recognize the fact that, this behavior can be a bit distracting sometimes.
I've had jobs like this a couple of times and they've always been my favorite. Unfortunately, later in my career I haven't been able to find or create this again. It seems like you have to stumble onto it from somewhere else in an organization.
I got hired because of an HN comment our founder saw. I told the story on the sister comment. Positions like this can only happen in startup level companies, where there is room for controlled chaos. Where founders can take chances and roll the dice with a hire.
I would have never made past the application process of a corporate software company, and a traditional HR might deem me to be unprofessional. I am very lucky to be in this position.
Get this. I got hired because of an HN comment [0]. I will write about the whole story someday.
Our founder is active on HN. I was applying to customer success engineer or technical support roles. Then one day, I mentioned my customer success strategy on a thread. The comment wasn't even top level. Our CEO saw it and he emailed me.
He told me that, he really liked my comment, and he was looking for someone like me for their very first hire for a DevRel position. I was very afraid to apply because developer relations or developer advocate roles usually require a more mature and professional software engineer. Someone who is part of the industry. I have been freelancing for around 5 years at that time, but never had any organizational experience and drop comments on HN and Reddit threads a lot.
We talked casually over email a bit than he offered me the job. It was really like a miracle to be honest. I have been in this role for 7 months, and I am very happy. This role was made for me. :D
I don't know if these advice still applies en 2023, mostly because at least on the "web" side of development there are so many solutions/frameworks/libraries releasing that look exciting but there aren't enough problems to be solved solely through software development in our daily lives.
Till this day i don't know were can i fit svelte/solidjs/remix in my current development environment without introducing more problems than solving issues but there is a crowd of young developers that learn from bootcamps these tools and start solving all the problems with the same tech (like why is everyone using nextjs for static content like devdocs?).
Sometimes is good to ask for problems to be solved, its more satisfying and challenging helping someone else rather than making another guitar mixer software that is a problem solved inside another software (ableton), also helps a lot to develop your professional skills because at the workplace you won't be the one using the software and you learn a lot of how people use your/the software.
This resonates strongly with me. I have no use for any of these technologies for any of the problems I face daily. The only problems these things solve are certain business problems which do not concern the individual.
This is both good advice, and completely useless advice.
> Stop and think about all of your personal interests and solve a simple problem related to one of them
As someone who has spent many years as an "aimless excited programmer", I would like to point out emphatically, that this idea did, in fact, occur to me.
So I thought about it. I asked myself that question.
But then what? I didn't have unsolved problems lingering in other hobbies. If I did, I would not have been aimless! This is specifically the task a person in this position is asking for help on.
Then there were the rare times that I did have unsolved problems, but they were always way too big to practice on.
Programming has two fundamental natures: abstraction and implementation. You can become an expert in the abstract, like a mathematician, but that doesn't make you an engineer.
Just like mathematicians manage to keep learning math without engineering, we can keep learning programming without ever programming. It's a very unsatisfying position to be in.
I have faced this myself, and the aimless excitement can create a lot of frustration in new programmers. Programming is a unique tool in the sense that it has the ability to glaringly show the programmer's lack (or wealth) of vision.
That's a fine advice for people with hobbies that use technology. For most of my activities outside of work, I've found that Excel is about as much software as I need.
RE key 1 ("keep it simple"), I'd like to add to extend this to tools. You don't need to learn tmux, vim, docker, kubernetes, CI/CD etc. in order to create useful things. Just use whatever you're comfortable with at the moment (including the mouse!), and don't ever feel that "real programmers" use some fancy and/or nerdy tools.
The article really seems to be attacking a bit of a straw man - for sure technology-first rather than utility-first isn't the right approach if you're looking to create products, but IMO neither of the examples he leads with are really falling into that trap.
The "suggest a large project I can do in language X" seems to be more about asking for something larger where the given language might be a good choice rather than asking for product ideas. The person asking the question would seem to just be wanting to get some more in-depth/real-world experience with the language they've just learnt and are excited about.
The "suggest a Windows program you'd like to see available on Linux" seems entirely reasonable from POV of market/utility-first. Maybe the newbie's enthusiasm isn't going to be enough to succeed, but no harm in trying to develop something that people actually want rather than coming up with your own toy project.
such a useful insight - that everyone knows but don't really use.
it's the same pit a lot of us engineers fall into - tryin' to solve a problem
in a domain we don't have much hands on experience with.
thinking just because there's a workable solution that's achievable via code.
then we write postmortems of why our startup, venture, product didn't work - while still ignoring the fact about domain knowledge.
which in terms of b2b software where there's a massive demand. few engineers including me - know domain experts that are not engineers.
Having done exactly that (tagging and collating app for images), I can report that it is likely to take somewhat longer than “an afternoon.”
The Programmer’s Credo:
We do what we do; not because it is easy, but because we thought it would be easy.