What it made me realize is that... I need to find myself something else to do than programming. Something else to learn about in greater detail. There are many, many interesting problems out there to solve, but you have to know about them first. Programming is great as a support speciality, if you have another one to support it. Right now the only thing I'm specialized in is making better tools for developers. Which we're in need of, true, but even more so are other domains.

[0] - Yesterday's talk should be up soon; in the meantime, here's his talk from last year at Google: https://www.youtube.com/watch?v=0rSMt1pAlbE.

Most of the most challenging software requires domain knowledge that CS/software devs do not have. Ultimately it is easier to go from a math/physics background to CS/software development than the other way round.

  There might be some light on the horizon, however.  I predict that in the not too distant
  future, people in acamedmic life are going to define themselves not by one specialty
  area, but by two sub-specialties that belong to two rather different main specialties.
  This means that we'll have a web of interests, in which each person will serve as a
  bridge between different parts of the overall structure.  You can see that this is much
  better than having a tree hierarchy that branches out further and further, with nobody
  able to talk to the people on other sub-branches.  We'll have people that each belong to
  two areas, in two different parts of the overall structure.  Then we'll be able to have
  some hope of coping with new knowledge as it comes along.

This is a new favourite quote of mine.

Also, because I'm in research, no-one is going to pay you for your work (or if you get paid, it will be embarrassingly small)

I'm not sure how many people there are who would be willing to invest a couple of weeks learning a new topic, to then write a program in that topic without pay. Oh of course, and probably useful to provide some minimal support going forwards as well.

I understand what you are saying about pay. But here is the counter argument for it - say you have 3 problems to solve, that can be solved with software. You don't have time or patience to code it yourself, but you know your peers and friends also have the same 3 problems. If you can clearly write down the requirements, I think there will be programmers who will be willing to work on the problem - especially if they know there are people who want the problems solved and there is a possibility of turning it into a side project or a business.

Maybe you could pick a handful of the problems, post them here and see if there is any interest?

>>> contribute to an open source project

It's a very very common advice and I believe a wrong one, especially to novice developers. It's simply... Not that easy. Yes, there are tons of projects but most of them are pretty damn large or mature enough so that easy tasks have been a long time ago. Some projects (e.g. servo) have web sites dedicated to new contributors where you can filter issues marked as easy but there are not many projects to choose from. You can look for small, less popular projects... But that's not an easy task either. Plenty of experienced developers have an issue 'want to contribute, don't know where' and they find it tricky, it's much harder for the novices.

[0] https://automatetheboringstuff.com/

I was going to hop in and say I keep a pad of paper where I just list out any process that I find myself doing rote, finding myself doing more than once, etc. A lot of it ends up being really simple. A six line bash script that concatenates my shopping lists from three text files when I am going to the store. A little python script that walks through a list of domain names, calls dig and dumps the output into a log file. I try to spend my computing time just thinking about how I can get more done with less keystrokes.

I'm around seven years into my career and only now do I feel comfortable with the idea of contributing to an open source project. You need to first work on a team whose workflow is structured in the manner that these projects work in (small, single purpose commits, reviews, etc.) and if that's not habituated, then simply figuring out how to do that first is a mountain in itself.

Sometimes, the bigger challenge with automation is getting users to see a service, function, or utility as the underlying algorithms and calls, and not as this immutable black box interface. Once viewed this way, it's easier to separate automation into more easily defined goals.

---

Foreach ($nonpayer in (Import-CSV ("C:\billing\" + (get-date -F MM) + ".CSV") | where {$_.pmt -eq 0})) { Send-MailMessage -from Billing@example.com -to $nonpayer.email -SMTPserver relay.example.com -title " Payment Overdue" -body "Hello $($nonpayer.first-name), your payment for $(get-date -f MMMM) was not received. Please send payment today."};

(I wrote this on the bus on my phone)

Besides, it's rare for DNS names to change; the point of DNS is the underlying server addresses can change without changing the name. And a service like SMTP relay should be less likely to change than other types of host.

But still, good point. This could easily be a Param if the function would be used in many environments.

PS C:\> New-Parameter SMTPSvr -TopHeader -BottomHeader -ParameterType string -DefaultValue "mail.example.com"

        Param(

                [string]$SMTPSvr = "mail.example.com"

        ) #end Param

It's incredible that we have highly skilled (and in demand) people who would like to work for free, and the problem is finding ways of letting them do that.

[1]https://medium.com/@hu_me/how-i-got-past-trying-to-reinvent-...

Doing calculations by writing functions, reading files, etc. is a great way to progress. One can take some equations from an intro physics/chem/bio book and get started. Or doing some budgeting/personal finance/investing simulations using personal banking CSVs or online stock data.

It's a good alternative to game programming in that it may be more obviously pragmatic and appeals to people (like myself) who are thoroughly uninterested in games. I imagine it's a very different style of programming as well; less interactive and more geared towards producing results rather than an experience.

For more experienced programmers looking for interesting and useful side projects (maybe to show off skills for a job search), I think there is a lot of opportunity to work with scientists to help them with their research. It's actually pretty easy to reach out to scientists by going to public talks and seeing what they do, then chatting them up and seeing how to make yourself useful. The hard part is of course sticking with it...

In paid gigs, you have hard or soft deadlines, commitments, etc. But sometimes you just want to code with no pressure, no deadlines, no managers, under total freedom and the money is not the first (and often not the second) priority.

That's why paid gigs often is not the answer.

You might get there with total freedom, but stress might get you there faster.

I suppose different people have different needs. I started with programming as a childhood hobby, and one thing I retained from that period of my life is the strong need for autonomy in the kind of projects I do, and in the way I do them. Which is, sadly, quite incompatibile with the way a typical employer wants you to work.

"How" is about yourself. "What" is about others. Both are important, but "How" ususally comes first. The best way to transition from "How" to "What" is to trust that you have enough "How" (you probably do) and talk to enough others to understand their "What". That oughta give you plenty to do.

In the software community the rule is "don't reinvent the wheel." It's almost frowned upon if you rewrite a library when a mature and stable option exists. While it is a good rule in general, novices should not be afraid to reinvent the wheel. When it is done for learning or practice, it's totally OK to make a wheel!

Yes! The best thing I've ever done to get better ("graduating" to the next level) was to rewrite something else. Sometimes because I thought it sucked, sometimes because it was so cool that I wanted to grok how it worked from the inside out, but never because it needed rewriting. I have never learned anything reading someone else's code. I have always learned tons rewriting it.

Don't get the notion that you need to have the best idea ever before you write a program either.

I never write anything in order to get ideas. I write stuff in order to fill my tool box with enough skills and wisdom so that when I do get an idea, I'll be able to run with it.

How many of you have been in the situation where you think "I don't know what to program?" How did you handle it? What advice would you give to others in that situation?

Just write something, anything. You probably won't know where this will take you, but rest assured, it will take you somewhere you never would have found by not writing it.

Great post! Thank you, OP.

Being able to generate the "what" is necessary even if you're working on other people's requirements. This is because other people's requirements are usually not so detailed that code will pop out. There are plenty of gaps where your creativity is required to go from the high level spec to the detailed spec. That's the design aspect of development.

The requirements leave out the "how": but hiding in every "how" is plenty of "what"! "This requirement doesn't say how such and such is to be achieved: what do we choose to satisfy that?"

Someone who has no idea or interest in programming something if left without external requirements is probably not a great designer; he or she is lacking at least some aspect of the "maker" instinct. The maker is defined by making; you would have to wrestle the craft out of a true maker's hands.

If you get a completely detailed spec handed to you, then you're just a "coding technician". Someone will make a programming language which directly executes such a spec, and you're obsolete.

For example, watching the Eurovision semi-finals last night I thought, "the lyrics are so cheesy and awful, I bet they could be written by a computer program", so I spent an hour or two writing a very simple Markov chain generator using input from all this years' English language entries to generate fake Eurovision songs.

The other weekend I wanted to play with React and HTML5 canvas, so I wrote a starmap/world generator for an old desktop SF RPG I used to play. I was listening to a podcast about that game so it got me thinking.

These are trivial ideas, certainly not earth-shaking or money-making, but they're good practice and fun to work on and if nothing else I can just add them to my Github portfolio.

Basically, if there's a product you've been looking for and can't find, make that. If that doesn't exist in your life at this moment... maybe hang tight until it does.

The vast, vast majority of the code I write is only used by me. It's not on github, it's not "published"; it's just to scratch an itch.

"Don't think of "problems" in the extreme sense. A problem to solve could be as simple as increasing efficiency of something by 1%."

Data asked why he is working on the engines Geordi says the engineer on another starship had his engines at something like 95%.

Then Geordi asks the computer for an update on the Enterprise's warp engine and the computer replies the engine efficiency increased a bit due to his changes.

http://memory-alpha.wikia.com/wiki/Force_of_Nature_(episode)

I have lots of big ideas. Big applications, distributed systems, etc. My experience tells me they would take months or years of dedicated work, even working with others. I already have a job.

I have lots of small ideas. I don't want to spend time on most of them because they're not particularly interesting to me. I don't want to write a TODO application that's perfectly suited to me, even though I want such a thing. I don't want to futz around with the UI and write all the mundane utility functions. There's no interest there for me.

So there's just nothing I'm particularly passionate about enough to motivate me to spend my time on it. And that's no big deal, at work the I have the luxury of other people thinking up the big problems and providing me with countless amazingly intelligent peers with whom to create things. And at home I have other hobbies.

Edit: So, I guess to crystallize some advice from that, at least for people who are similar to me: try to get a job that satisfies your "I want to code amazing things" itch, and then enjoy everything else the world has to offer outside of work.

Make a Wikipedia for code. Not a wikipedia about code, but a Wikipedia where the pages are the code. No references to outside tools/libraries, all the functions are either in the base language or references to other wikipedia-of-code pages. The pages are presented in a literate programming style.

Bring back the Inferno OS, but replace the original VM (Dis) with the Microsoft CLR.

Make a P2P publishing system for scientific publications. Let the contributing scientists have individual accounts, and manage reputations with a blockchain reputation system. Let people also donate their CPU cycles to scientific computations through this system. Require publications to store their data in a database format that your system's client can query and process with some programming language. Require all data tables, and results that appear in the publication's text be expressed as functions performed on data queried from the database (or potentially databases from other publications.)

I've been successful enough with my ideas that I just hire programmers and designers and just bootstrap everything myself. It's just easier that way.

Even professional programmers can get that feeling when looking at some of the really popular apps/webapps/games. You have to keep in mind though that none of those are built by a single person but by at least a couple of people (usually dozens upon dozens). The key is to start small but to start somewhere and keep going.

https://en.wikipedia.org/wiki/TempleOS

I understand all dev jobs will have some grunt work, but once you've been doing it for 10+ years, it gets harder to work on mostly grunt work. My brain needs something more challenging.

Still not thinking of anything? Go outside and play until you find something.

Edit: I didn't read the entire article. I couldn't get beyond the music comparisons. Rockstars in music get a lot more money and fun than rockstars in programming do.

Still not thinking of anything? Go outside and play until you find something.

I can think of Bill Gates, John Carmack, Sergey Brin, or even Mark Zuckenberg as counter examples :)

One comes from simply the problem at hand being large / complex and that's something that might be really hard to come up with.

However, it can also be challenging because of unfamiliar tech stack. Be it a new language, new framework, etc. Going too far in this direction can lead to projects being too hard to complete so you want to balance it with familiar technologies as well. For example, if you are familiar with Python and Javascript, picking Elexir and CoffeeScript might be too much. However, Python and CoffeeScript would make a good combination. You get the idea.

What does that have to do with the topic of knowing how to program, but not having a what? That is shifing the topic to "I don't know how to program very well; how can I get more practice".

How about developing an expert assistant program which helps writers stay focused on a topic?

People who actually know how to develop can have this problem.