I did a Q&A a few days ago, and one of the questions was "How does one break the toy project / codecademy cycle?" ... I am not sure what that means, but I will take this as an opportunity to rant about something I care about that seems (to me) vaguely related.
You may be feeling like you are trapped in a cycle of just learning things, using them in a toy project and then... what? You learn something else? And do another toy project? And so on?
And you feel like that is totally meaningless and gives you no feeling of achievement, no motivation, and end up feeling like you are going to be a newbie forever?
Well, if that's the case ... listen to me.
Your toy projects feel meaningless because they are not real.
That feeling you have? It's just your inner programmer telling you to stop playing around and start proogramming for real. And I am here to tell you how to do that.
STEP 1: Find something you need your computer to do that it doesn't do
You want your Youtube videos to appear in your blog?
You want to be know how many people called Roberto were born in 1934 in Argentina?
Well, imaginary person, after you found something like that, you can move to step 2.
Let's say you have decided to implement a gadget that drives away the birds that wake you up every morning in this endless nightmare we currently live in.
STEP 2: Decide some basic details about your goal
This is what is called a project. Implementing sorting algorithms is not a project, that's an exercise. Implementing the 200th version of a chat using websockets for your "portfolio" is not a project, it's, I don't know, a boring addendum to your resumé or something.
A project is a goal. A project is "I want my computer to do THIS and in the holy name of Billy Wilder, I intend to spend the effort to make it do it!"
So: I want something that when it detects bird sounds, makes noise to drive them away.
- Listens for noises
- Decides whether they are bird noises
- Answers with a noise that is unpleasant to birds
STEP 3: Convince yourself that's a possible thing computers can do
Because, you know, computers can do a lot of things, but computers can't do everything. So, you need a quick reality check. Make it very quick, you don't want to spend more than, like, half an hour on it.
- Can computers listen for sounds? Yeah.
- Can computers make sounds? Yep.
- Can sounds drive away birds? Yes sir!
- Can a computer decide whether the noise it hears is a bird or not? Well, maybe? I have seen stranger things!
STEP 4: Come up with a semi-rational mechanism to implement it
This has to be very vague. Like "yeah, I can do that using this Google API and this piece of lint I found in my sofa". A vague idea.
- Implement something that listens for noise.
- Add something in the middle that decides if noise is bird-like
- Make noise detection trigger code
- Implement something that makes noise
STEP 5: Come up with the most stupid version of the goal you can imagine
So, you want to write a bird-detector? Try writing a noise-detector, first. Or rather, try to find something that can react when your microphone detects noise. Or even, find a library that gives you access to your microphone.
- Find a library to read sound from microphone
- Detect noise
- Find library to make noise
- Make noise
- Connect both pieces
STEP 6: sit the fuck down and implement the stupid version
This should be done FAST. If you plan too much you are not going to do anything other than plan a lot. You want to become a programmer, not a PM. I wonder what the PM version of this rant would look like.
STEP 7: Show the stupid version to someone you respect, and listen
Yes, this part is scary, but programming is, in large part, about people. Showing things to people, listening to people, finding out what people really mean, and so on.
So: show it to someone. Listen. Make decisions about whether you were right in steps 3 and 4. Maybe adjust a little what yoour goal is.
STEP 8: repeat step 5 to 7 with a slightly less stupid version
Do this until you run into something you have no idea how to do. In this case that's probably going to be "decide if that's a bird's sound"
STEP 9: get help
Ask around. Again, programming is mostly about people. In this case, you will practice "getting help". You don't want someone to just tell you how (or maybe yes?) but this is the critical point.
You can run into a few scenarios.
- You figure it out.
- You figure out that it can't be done.
- You find out that it's doable but you just have no idea how.
If you figure it out, then there is no problem! Go back to step 5 and continue until you are happy with the project, and you have learned something new! Congratulations!
The other two outcomes lead to ...
STEP 10: get stuck
If you figured out that it can't be done, then you have learned about one type of problem that is currently intractable. Considering you are new to this sort of thing, that is probably not something you are going to solve, but ... if you really were interested in this project, it may point you to a whole kind of thing you want to learn about.
So, you can't decide if a given noise is a bird ... why? Is there research being done in that area? Would that involve machine learning? Hey, that sounds interesting. Usually the examples are about images... is there any interesting work being done about applying it to audio? Are there libraries? Are there datasets? Are there tutorials? Hmmm ... and now you know something you want to learn about. Have fun.
The third outcome is the complicated one. Let's say it can be done by creating a model with ML and a dataset of urban noises and a dataset of bird noises and both things exist, and it has been done, and you know about it (a little) but you have no idea how to do it.
Well, in that case ... congratulations, you have found the current limit of your competence. You just need to expand it. And that's what programming is like.
So, how does this whole convoluted process help you?
You are learning different things you won't learn doing exercises.
- You learn to decide what to do.
- You learn to ask for help.
- You learn to present your work to others.
- You learn to process feedback.
- You learn to research your problem space.
- You learn to break down tasks.
- You learn to make decisions.
And yes, you may learn a programming skill or two.
And, maybe (but it's unlikely) you will get rid of those pesky morning birds.
If you are interested in a long comment thread about this, of which roughly 30% missed the point of this not being some sort of universal advice and therefore taking personal offense at it, and 50% is me responding to each and every comment, see reddit.
Es difícil levantarse, es difícil laburar, es difícil parar de laburar, es difícil descansar, es difícil dormir, es difícil cocinar, es difícil pedirle al otro que cocine, es difícil no cocinar y pedir delivery, es difícil salir a hacer las compras, es difícil no salir, es difícil ir a la terraza, es difícil la reunión por zoom, es difícil concentrarse, es difícil programar, es difícil hacer videos, es difícil leer, es difícil escuchar música, es difícil distraerse, es difícil el chat del laburo, es difícil el chat de amigos, es difícil twitter, es difícil el noticiero, es difícil escribir, es difícil.
It has been a little over a week since I committed to using a tiling window manager.
Sure, I am cheating because I am actually still using KDE plus Kröhnkite but my windows are tiled and I am liking it a lot.
Why this and not i3 or whatever? Because I don't want to change my lifestyle, I just want my windows to not overlap generally.
Kröhnkite provides enough tiling functionality that I get (I think) the benefits without the massive upheaval of giving up everything I am used to in my desktop. I still use the Windows Key (ok, ok, the "Meta" key) to launch apps. I still have a plasma panel with plasmoids at the bottom of my monitor, I can still float the windows if I want to! I can still use most of the shortcuts from my past 24 years using KDE (yes, really) and so on.
What are some things I had to change to adapt?
I had to change to focus-follows-mouse. BUT for the first time since I started using FVWM in 1993 I am liking focus-follows-mouse better than click-to-focus. It turns out KDE's implementation of it is quite nice and almost "does what I mean". As it says in the docs, "like click to focus, but just don't click".
I removed window decorations. Yes, you can keep them, but they feel out of place.
I set thicker window borders. Resizing windows via shortcuts is just not nice in general, so thicker borders help.
What are some things I have liked?
Fixed tiling layout in one monitor and floating in the other is awesome when needed. And I can get it in place with one keypress! So, in general, dynamic, separate layouts for each screen is very, very useful.
Having a "tiling" wm that still respects most WM conventions is good. So, popups float. Yay.
Alt+Entershortcut to make a window the "important" one is neat.
Love how maximization/minimization works.
What are some things I have not liked?
The "tiled" layout has multiple versions you can switch between with Ctrl+I/D ... and well, sometimes none of them is exactly what I want? Also, the higher numbered ones only are useful when you have many windows tiling, and if you don't they don't do anything.
Since I have no window decorations, the brutal inconsistency on app-quitting shortcuts is annoying. It can be
escor whatever. I end up doing
alt+f4which feels like windows 3.11.
The UX of KWin scripts is a bit lacking. I installed another one a while ago, called Quarter-Tiling, and I have removed every trace of it from my system... except for its shortcuts, which will apparently pollute my config dialogs forever.
So, experiment will continue!
(Sorry, the video is in spanish)
Preguntas de gente! Respuestas de mí!
Perdón por el sonido, moví el micrófono de lugar, quedó más cerca y el sonido clipea, lamentablemente soy demasiado haragán como para grabarlo de nuevo.
- Entrevistas de trabajo: https://youtu.be/ICndfSG1Or4