Advice to Aimless, Excited Programmers (2010)

<i>&gt; I also take a lot of photographs, and I could use a tagging scheme that isn&#x27;t tied to a do-everything program like Adobe Lightroom. That&#x27;s simple enough that I could create a minimal solution in an afternoon.</i><p>Having done exactly that (tagging and collating app for images), I can report that it is likely to take somewhat longer than “an afternoon.”<p>The Programmer’s Credo:<p><i>We do what we do; not because it is easy, but because we thought it would be easy.</i>

Good advice to advance your career, but I&#x27;d say there&#x27;s nothing wrong with being passionate&#x2F;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&#x27;t be picky about the domain, but they will probably earn less as they won&#x27;t ever be domain experts).<p>There are endless examples from other &quot;industries&quot;. 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.<p>It&#x27;s not &quot;wrong-way-aroundness&quot;, it&#x27;s just a different goal.

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.<p>This is true, but the reason this is <i>advice</i> (ie, suggestions of the best course of action) is that if you can get your enjoyment to line up with what&#x27;s useful, your life gets better than if you keep it separate.<p>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 &quot;tune&quot; your mind to enjoy something practical, potentially that thing can grow and you can do it full time (ie also enjoy your job)<p>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.

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 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&#x27;t frame it, don&#x27;t care, I enjoyed doing it.<p>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.<p>This is true, sometimes, but other times, what happens is the solution is over fitted to the person who wants it.<p>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.

&gt; Would you trust a music notation program developed by a non-musician? A Photoshop clone written by someone who has never used Photoshop professionally?<p>Wouldn&#x27;t a fresh look at things, essentially a &quot;clean room&quot; implementation offer the possibility of a novel approach to a thing or two, as opposed to making the same tool, just different?<p>But overall the idea of matching one&#x27;s ambitions (project scope) to one&#x27;s abilities (including domain knowledge) is a good one.<p>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&#x27;s also useful to fail and be humbled with learning projects, especially when someone&#x27;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&#x27;m an aimless curious person, I like to enter new domains and grab the low hanging fruits where I can add value with &quot;code&quot;.

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, &quot;engineer&quot;, I don&#x27;t do product building.<p>I don&#x27;t have any exact direction honestly. We have a data product and I do random things as long as it improves the developer experience.<p>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.<p>It is chaotic and I really don&#x27;t have an exact year-long focus when it comes to programming commitment. The only thing that is true is that the API&#x2F;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.<p>&quot;Being aimless and always excited&quot; 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.<p>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.

I don&#x27;t know if these advice still applies en 2023, mostly because at least on the &quot;web&quot; side of development there are so many solutions&#x2F;frameworks&#x2F;libraries releasing that look exciting but there aren&#x27;t enough problems to be solved solely through software development in our daily lives.<p>Till this day i don&#x27;t know were can i fit svelte&#x2F;solidjs&#x2F;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?).<p>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&#x27;t be the one using the software and you learn a lot of how people use your&#x2F;the software.

This is both good advice, and completely useless advice.<p>&gt; Stop and think about all of your personal interests and solve a simple problem related to one of them<p>As someone who has spent many years as an &quot;aimless excited programmer&quot;, I would like to point out <i>emphatically</i>, that this idea did, in fact, occur to me.<p>So I thought about it. I asked myself that question.<p>But then what? I didn&#x27;t <i>have</i> unsolved problems lingering in other hobbies. If I did, I would not have been aimless! This is <i>specifically</i> the task a person in this position is asking for help on.<p>Then there were the rare times that I <i>did</i> have unsolved problems, but they were always way too big to practice on.<p>Programming has two fundamental natures: abstraction and implementation. You can become an expert in the abstract, like a mathematician, but that doesn&#x27;t make you an engineer.<p>Just like mathematicians manage to keep learning math without engineering, we can keep learning programming without ever <i>programming</i>. It&#x27;s a very unsatisfying position to be in.

Now go back and read Linus Torvalds&#x27; first note on writing Linux.[1]<p>[1] <a href="https:&#x2F;&#x2F;fossbytes.com&#x2F;linus-torvaldss-famous-email-first-linux-announcement" rel="nofollow">https:&#x2F;&#x2F;fossbytes.com&#x2F;linus-torvaldss-famous-email-first-lin...</a>

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&#x27;s lack (or wealth) of vision.

That&#x27;s a fine advice for people with hobbies that use technology. For most of my activities outside of work, I&#x27;ve found that Excel is about as much software as I need.

Good advice.<p>RE key 1 (&quot;keep it simple&quot;), I&#x27;d like to add to extend this to tools. You don&#x27;t need to learn tmux, vim, docker, kubernetes, CI&#x2F;CD etc. in order to create useful things. Just use whatever you&#x27;re comfortable with at the moment (including the mouse!), and don&#x27;t ever feel that &quot;real programmers&quot; use some fancy and&#x2F;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&#x27;t the right approach if you&#x27;re looking to create products, but IMO neither of the examples he leads with are really falling into that trap.<p>The &quot;suggest a large project I can do in language X&quot; 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&#x2F;real-world experience with the language they&#x27;ve just learnt and are excited about.<p>The &quot;suggest a Windows program you&#x27;d like to see available on Linux&quot; seems entirely reasonable from POV of market&#x2F;utility-first. Maybe the newbie&#x27;s enthusiasm isn&#x27;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&#x27;t really use. it&#x27;s the same pit a lot of us engineers fall into - tryin&#x27; to solve a problem in a domain we don&#x27;t have much hands on experience with. thinking just because there&#x27;s a workable solution that&#x27;s achievable via code.<p>then we write postmortems of why our startup, venture, product didn&#x27;t work - while still ignoring the fact about domain knowledge.<p>which in terms of b2b software where there&#x27;s a massive demand. few engineers including me - know domain experts that are not engineers.

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.

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

I&#x27;m the opposite, plenty ideas and I know I can achieve them but picking stack gets me paralysed...

I&#x27;m loving the dadgum renaissance here. He had so many great articles.

aka scratch your own itch