9 ms·

Advice to Aimless, Excited Programmers (2010)

277 points by weird_user 4y ago

dzonga 4y ago
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.
KronisLV 4y ago
> 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.
- PaulHoule 4y ago
  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.
  - KronisLV 4y ago
    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 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.
    - oriolid 4y ago
      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.
- Cthulhu_ 4y ago
  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.
- munchbunny 4y ago
  > 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.
  - wtetzner 4y ago
    > 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.
- jayd16 4y ago
  That analogy is pretty pointless, anyhow. I trust a desk made by a carpenter not a writer. I don't expect a kitchen made by a cook.
amonith 4y ago
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.
- Ensorceled 4y ago
  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.
  - amonith 4y ago
    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.
    - AuthorizedCust 4y ago
      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.
is_true 4y ago
I'm an aimless curious person, I like to enter new domains and grab the low hanging fruits where I can add value with "code".
- aleph_minus_one 4y ago
  If your comment is not intended as a joke: 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".
  - is_true 4y ago
    Not a joke. I usually end up creating better workflows automating tasks
  - comicjk 4y ago
    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.
    - aleph_minus_one 4y ago
      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).
  - hgsgm 4y ago
    Please don't destroy people workflows into a locked up app and then run off to the next gig.
    - is_true 4y ago
      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
freetonik 4y ago
Good advice. 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.
teddyh 4y ago
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.
- ramraj07 4y ago
  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.
- cfiggers 4y ago
  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.
pedrolins 4y ago
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.
oytis 4y ago
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.
black_13 4y ago
[dead]
jesikafernandes 4y ago
[dead]
deleted 4y ago
[deleted]
anyfactor 4y ago
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.
- developer93 4y ago
  That sounds like an amazing job, which I never heard of. How did you get into that?
  - anyfactor 4y ago
    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 [0] https://news.ycombinator.com/item?id=31857069#31858624 https://news.ycombinator.com/item?id=31857069#31858624
rileymat2 4y ago
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.
SadWebDeveloper 4y ago
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.
- fud101 4y ago
  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.
HarHarVeryFunny 4y ago
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.
xyzelement 4y ago
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.
- topaz0 4y ago
  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.
trimethylpurine 4y ago
This advice is best suited for entrepreneurs generally. Programming for fun is fine, just don't expect my money to be involved.
hyperthesis 4y ago
aka scratch your own itch
ChrisMarshallNY 4y ago
> 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.
- whitemary 4y ago
  Very well put
- cyrialize 4y ago
  Absolutely. This is probably why I have 4 times as many started & abandoned projects versus finished ones, haha.
- r3trohack3r 4y ago
  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. https://wikiscroll.blankenship.io https://wikiscroll.blankenship.io 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. https://audile.blankenship.io https://audile.blankenship.io 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 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.
LAC-Tech 4y ago
I'm loving the dadgum renaissance here. He had so many great articles.
throwaway290 4y ago
I'm the opposite, plenty ideas and I know I can achieve them but picking stack gets me paralysed...
lasereyes136 4y ago
I really miss this blog. It was great and had solid advice and points of view. I am glad a lot of the articles hold up after all these years.
thomastjeffery 4y ago
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.
Animats 4y ago
Now go back and read Linus Torvalds' first note on writing Linux.[1] [1] https://fossbytes.com/linus-torvaldss-famous-email-first-linux-announcement https://fossbytes.com/linus-torvaldss-famous-email-first-lin...

277 points by weird_user 4y ago

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.

KronisLV 4y ago

> 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.

PaulHoule 4y ago
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.
- KronisLV 4y ago
  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 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.
  - oriolid 4y ago
    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.
Cthulhu_ 4y ago
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.
munchbunny 4y ago
> 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.
- wtetzner 4y ago
  > 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.
jayd16 4y ago
That analogy is pretty pointless, anyhow. I trust a desk made by a carpenter not a writer. I don't expect a kitchen made by a cook.

amonith 4y ago

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.

Ensorceled 4y ago
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.
- amonith 4y ago
  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.
  - AuthorizedCust 4y ago
    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.

is_true 4y ago

I'm an aimless curious person, I like to enter new domains and grab the low hanging fruits where I can add value with "code".

aleph_minus_one 4y ago
If your comment is not intended as a joke: 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".
- is_true 4y ago
  Not a joke. I usually end up creating better workflows automating tasks
- comicjk 4y ago
  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.
  - aleph_minus_one 4y ago
    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).
- hgsgm 4y ago
  Please don't destroy people workflows into a locked up app and then run off to the next gig.
  - is_true 4y ago
    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

freetonik 4y ago

Good advice. 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.

teddyh 4y ago

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.

ramraj07 4y ago
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.
cfiggers 4y ago
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.

pedrolins 4y ago

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.

oytis 4y ago

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.

black_13 4y ago

[dead]

jesikafernandes 4y ago

[dead]

deleted 4y ago

[deleted]

anyfactor 4y ago

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.

developer93 4y ago
That sounds like an amazing job, which I never heard of. How did you get into that?
- anyfactor 4y ago
  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 [0] https://news.ycombinator.com/item?id=31857069#31858624 https://news.ycombinator.com/item?id=31857069#31858624

rileymat2 4y ago

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.

SadWebDeveloper 4y ago

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.

fud101 4y ago
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.

HarHarVeryFunny 4y ago

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.

xyzelement 4y ago

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.

topaz0 4y ago
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.

trimethylpurine 4y ago

This advice is best suited for entrepreneurs generally. Programming for fun is fine, just don't expect my money to be involved.

hyperthesis 4y ago

aka scratch your own itch

ChrisMarshallNY 4y ago

> 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.

whitemary 4y ago
Very well put
cyrialize 4y ago
Absolutely. This is probably why I have 4 times as many started & abandoned projects versus finished ones, haha.
r3trohack3r 4y ago
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. https://wikiscroll.blankenship.io https://wikiscroll.blankenship.io 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. https://audile.blankenship.io https://audile.blankenship.io 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 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.

LAC-Tech 4y ago

I'm loving the dadgum renaissance here. He had so many great articles.

throwaway290 4y ago

I'm the opposite, plenty ideas and I know I can achieve them but picking stack gets me paralysed...

lasereyes136 4y ago

I really miss this blog. It was great and had solid advice and points of view. I am glad a lot of the articles hold up after all these years.

thomastjeffery 4y ago

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.

Animats 4y ago

Now go back and read Linus Torvalds' first note on writing Linux.[1] [1] https://fossbytes.com/linus-torvaldss-famous-email-first-linux-announcement https://fossbytes.com/linus-torvaldss-famous-email-first-lin...