What eight years of side projects have taught me (2019)(junglecoder.com)
junglecoder.com
What eight years of side projects have taught me (2019)
https://www.junglecoder.com/blog/idea-chain-themes
90 comments
One thing that's always helped me in interviews is to bring these side projects - physically - into the interview. Often it's customary to not bring anything but your resume. I typically bring a print-out of my projects, some GitHub code, some documentation samples, and maybe even my laptop with projects pre-opened so that we have things to talk about.
I always qualify this as "just in case you are interested", but they are almost always interested. Nobody wants to talk about a bland resume; they'd rather talk about the things you found a genuine interest in.
I always qualify this as "just in case you are interested", but they are almost always interested. Nobody wants to talk about a bland resume; they'd rather talk about the things you found a genuine interest in.
I've had co-workers remember, years after interviewing me, that I brought in some little piece of hardware I built to the interview.
I've showed off circuit boards, half-baked Android apps and referenced webpages during interviews. It always helps.
A couple years ago at an interview debrief, the HR guy said, "Oh, the candidate told me that he was writing some kind of software to automate his home. Who would do that? Weird." And every developer in the room looking at each other and saying "and you didn't think to tell us that?"
I've showed off circuit boards, half-baked Android apps and referenced webpages during interviews. It always helps.
A couple years ago at an interview debrief, the HR guy said, "Oh, the candidate told me that he was writing some kind of software to automate his home. Who would do that? Weird." And every developer in the room looking at each other and saying "and you didn't think to tell us that?"
I've done this before (just the laptop and an HDMI cable) and also had success with it.
It sort of wakes people up out of a traditional interview expectation and instead they now have to actually listen to what I'm saying rather than going through canned questions and answers.
It sort of wakes people up out of a traditional interview expectation and instead they now have to actually listen to what I'm saying rather than going through canned questions and answers.
Hey, I know it's just a small comment on HN so I don't know the whole picture and you very well may already know/do this, but people who tend to have free time to just pump out side projects without worrying about work tend to be already-privileged people.
I get what you mean about not even really needing the project to work, just show that you have an idea and wanna work on it, yadda yadda, but I think you'll eliminate some good candidates and hard workers if you see a lack of side projects as a lack of devotion or work ethic.
I get what you mean about not even really needing the project to work, just show that you have an idea and wanna work on it, yadda yadda, but I think you'll eliminate some good candidates and hard workers if you see a lack of side projects as a lack of devotion or work ethic.
No I get it, you're right. It's not that I'm counting them out, it's more of an advantage that people with side projects tend to have, but it's super individual and my opinion is just one of many.
No, they are not right, they are very very wrong and probably just using this an excuse to be lazy; don't let people shame you for actually doing something.
weird, at the hackspace I went to, there were plenty of "under-privileged" people doing amazing side work for the fun of it.
Do we really need to start shaming people that actually do cool stuff?
Do we really need to start shaming people that actually do cool stuff?
I've had the same experience, but just wanted to sum this up as it's advice I've given to others: make side projects public.
This doesn't even have to be fancy, even just a list of projects on your own personal site with links to Github and what you learned/what you hoped to accomplish.
Having the public list is also good as many times the projects might be done at the behest of a company or you don't have a good way to "show" them so it's your chance to write them up and get "credit" for your work on them.
This doesn't even have to be fancy, even just a list of projects on your own personal site with links to Github and what you learned/what you hoped to accomplish.
Having the public list is also good as many times the projects might be done at the behest of a company or you don't have a good way to "show" them so it's your chance to write them up and get "credit" for your work on them.
But there are lots of people who just learn without "polluting" the world with unfinished or finished but useless projects. Many don't see reason to dump yet another toy compiler, toy OS or similar project. i.e. it's not just "only did school" alternative.
What's your path from developer to C-Level?
I feel like the companies I've been at don't really let developers move up to management positions, unless you come from the outside or somehow gained management skills somewhere.
I started out in product management, junior level. Then product owner (focus mobile) later on head of product and then c-level.
Developers (or PMs) who are interested in the business they work in and participate actively tend to get promoted/pushed. You have to understand the business perspective if you want to move up and get away from the thought of "I'm just here to develop and if I make the product great, everyone will recognize my talent/skill"
Developers (or PMs) who are interested in the business they work in and participate actively tend to get promoted/pushed. You have to understand the business perspective if you want to move up and get away from the thought of "I'm just here to develop and if I make the product great, everyone will recognize my talent/skill"
Are unfinished projects worth anything to an prospective employer?
I have plenty of projects I attempted before getting busy with real life. Should I show those when asked for a Github?
YMMV, but when I interview as an employer is ask a candidate to talk me through a project they really enjoyed. It can be work-based or a side-project, doesn't matter as long as it's something they really enjoyed. We then use that to explore what it was that excited them, the technology decisions they made, etc.[1]
If your answer was an unfinished project, I'd want to know why they were unfinished. Did you give up on them because of external pressures, you had a better idea, or because you often struggle to finish things you've started?
That last one is not alway a pejorative statement, BTW. Some people are great at figuring out the big stuff and then need others to help them execute on the detail (think about architects or producers). Others however, just give up at the first obstacle they meet, and if I get that impression from a candidate I'd want to dig into it a bit as it's possibly a yellow flag.
My advice then: think carefully about what they are likely to ask you about those unfinished projects, and what your answers are likely to be, before you offer them up.
[1] The most interesting answer to this question I've had was "an OpenGL renderer for the X Window System written in Lisp". My follow-up questions were many...
If your answer was an unfinished project, I'd want to know why they were unfinished. Did you give up on them because of external pressures, you had a better idea, or because you often struggle to finish things you've started?
That last one is not alway a pejorative statement, BTW. Some people are great at figuring out the big stuff and then need others to help them execute on the detail (think about architects or producers). Others however, just give up at the first obstacle they meet, and if I get that impression from a candidate I'd want to dig into it a bit as it's possibly a yellow flag.
My advice then: think carefully about what they are likely to ask you about those unfinished projects, and what your answers are likely to be, before you offer them up.
[1] The most interesting answer to this question I've had was "an OpenGL renderer for the X Window System written in Lisp". My follow-up questions were many...
> That last one is not alway a pejorative statement, BTW. Some people are great at figuring out the big stuff and then need others to help them execute on the detail (think about architects or producers). Others however, just give up at the first obstacle they meet, and if I get that impression from a candidate I'd want to dig into it a bit as it's possibly a yellow flag.
The most common reason for me to ditch a side project is that I've gained what satisfaction is to be gained from making it. For example, I want to try or learn some new thing and convince myself I can do it. Once I'm far enough to know how it works (even if it's not really doing much yet), I'm satisfied and I can move on to the next interesting thing.
That's why I have basically no side projects to show off..
The most common reason for me to ditch a side project is that I've gained what satisfaction is to be gained from making it. For example, I want to try or learn some new thing and convince myself I can do it. Once I'm far enough to know how it works (even if it's not really doing much yet), I'm satisfied and I can move on to the next interesting thing.
That's why I have basically no side projects to show off..
Follow-up:
Where do you think my time would be better spent preparing for a new job? Making a sideproject I can show off or doing interview puzzles?
High-pay or high-reputation jobs where the employer can be selective (FAANG, quant finance) seem to test for high IQ with interview "puzzles" (computer science puzzles of course).
Good employers, but who do not have more qualified candidates than they know what to do with, are already very happy with someone who simply has an interest in his job, as this is already rare enough. They pay attention to personal projects as signs that you actually belong in IT.
Government and, by extension, the consultancies that cater to them, pay attention to diplomas. Bureaucracies recognizing the stamp of approval of another bureaucracy, is one way of looking at it.
Good employers, but who do not have more qualified candidates than they know what to do with, are already very happy with someone who simply has an interest in his job, as this is already rare enough. They pay attention to personal projects as signs that you actually belong in IT.
Government and, by extension, the consultancies that cater to them, pay attention to diplomas. Bureaucracies recognizing the stamp of approval of another bureaucracy, is one way of looking at it.
If you're going for a bigger tech firm, they're more likely to ask you to do the interview puzzle format.
Learning how to do those is a useful skill in its own right, even if they're "toy problems", because what you're learning is a process to break a problem down, and then make a choice based on your knowledge of data structures and algorithms about how to approach it.
Getting good at those puzzles means you flex muscles related to:
- Problem breakdown into logical steps, or what I now call "the useful thing CS50 actually teaches"
- Data Structures
- Algorithms
- Communicating your thought process on all of the above
Those skills are going to help you in any developer job, but might also give you more confidence to take on side projects you wouldn't otherwise. You might look at something out there and think "woah, I want to go figure that out", and now your mental muscles are slightly better trained for it.
What I want when interviewing isn't necessarily a good guide, but typically the technical skills are a baseline and then I want:
- People who can be mentored and aren't know-it-alls. A touch of humility about them. Finds pairing whilst driving scary but will try it.
- People who want to mentor others. Finds pairing whilst not driving scary or frustrating, but will try it.
- Able to work within a team towards a common goal
- Will take ownership and accountability of their own individual tasks
These are things you're more likely find from previous work experience and maybe in side projects, at a push.
Learning how to do those is a useful skill in its own right, even if they're "toy problems", because what you're learning is a process to break a problem down, and then make a choice based on your knowledge of data structures and algorithms about how to approach it.
Getting good at those puzzles means you flex muscles related to:
- Problem breakdown into logical steps, or what I now call "the useful thing CS50 actually teaches"
- Data Structures
- Algorithms
- Communicating your thought process on all of the above
Those skills are going to help you in any developer job, but might also give you more confidence to take on side projects you wouldn't otherwise. You might look at something out there and think "woah, I want to go figure that out", and now your mental muscles are slightly better trained for it.
What I want when interviewing isn't necessarily a good guide, but typically the technical skills are a baseline and then I want:
- People who can be mentored and aren't know-it-alls. A touch of humility about them. Finds pairing whilst driving scary but will try it.
- People who want to mentor others. Finds pairing whilst not driving scary or frustrating, but will try it.
- Able to work within a team towards a common goal
- Will take ownership and accountability of their own individual tasks
These are things you're more likely find from previous work experience and maybe in side projects, at a push.
I had side project and nobody cared when I was looking for job. Like, it did not seemed to matter or do difference.
One hiring manager let me talk about it more, but in retrospect he was basically nice to me and let me talk about it because I wanted to.
One hiring manager let me talk about it more, but in retrospect he was basically nice to me and let me talk about it because I wanted to.
I agree with the people who answered before me. The smaller the startup the more important your side project could be. The bigger the company, the more streamlined the hiring process and the more likely that you would encounter puzzles etc.
I'd say if you're going for FAANG-type companies, definitely prepare for the puzzles and quizzes, but for a more smaller one (let's say sub-100 people) go for the side project approach.
Exceptions do apply obviously: I've had friends who got hired at FAANG because of a side project that grew and got the attention of the engineers at said company.
I'd say if you're going for FAANG-type companies, definitely prepare for the puzzles and quizzes, but for a more smaller one (let's say sub-100 people) go for the side project approach.
Exceptions do apply obviously: I've had friends who got hired at FAANG because of a side project that grew and got the attention of the engineers at said company.
> unfinished projects
Just redefine the scope, or the success criteria!
If the project's purpose was to learn or experiment with X, it doesn't matter that it's not a polished product, it still served its purpose and as such can be considered done.
Just redefine the scope, or the success criteria!
If the project's purpose was to learn or experiment with X, it doesn't matter that it's not a polished product, it still served its purpose and as such can be considered done.
This.
What is finished anyway? Are projects ever "finished"?
What is finished anyway? Are projects ever "finished"?
> unfinished projects
Depends on the definition of "unfinished" - it's good to create something that's workable to some state (or at least demo something). If you're using a repo of unrunnable code as an example of your skills, you probably need to have a robust explanation of what needs to be done to get it working.
However, I doubt lots of examples of half-complete projects will reflect too well, and might be more of a hindrance ("doesn't follow through, constantly jumping from thing to thing...") than a benefit. Pick one you're proud of and run with it, even if it's just a "this is the state, this is what I'd do to get it running...".
Depends on the definition of "unfinished" - it's good to create something that's workable to some state (or at least demo something). If you're using a repo of unrunnable code as an example of your skills, you probably need to have a robust explanation of what needs to be done to get it working.
However, I doubt lots of examples of half-complete projects will reflect too well, and might be more of a hindrance ("doesn't follow through, constantly jumping from thing to thing...") than a benefit. Pick one you're proud of and run with it, even if it's just a "this is the state, this is what I'd do to get it running...".
Pick one you're proud of and have the rest of the unfinished stuff as private repos.
I do - assuming there’s actually something to show off then I put it up. I have static websites only half full of content, repositories with just an assortment of scripts and configs, libraries that are just enough to meet the use case, etc
If that is the case, wouldn't it be better to hone design and product skills instead of coding?
I learned product management skills from writing my unpopular side projects and responding to my users.
If you're doing it even partly for purposes of looking good in an interview, I can assure you that it really doesn't matter. Pretty much anything you do other than just "I wrote this code at company A to do features B,C & D" will immediately set you apart from the crowd.
I've interviewed well over 100 people and I can count on the fingers of one hand the number that even mentioned some kind of side project.
I've interviewed well over 100 people and I can count on the fingers of one hand the number that even mentioned some kind of side project.
I completely can relate to your experiences (wrote a post about side projects [1]). Strongly agree with "Programming in a void is worthless". Learning a new language shouldn't be the purpose to start a new project, it should just be a tool to get a side project going. And the goal of the side project will make you force you to use it, so it's a great way to learn. It can sometimes be a struggle to learn how to achieve X or Y with that tool, I now tend to use the language I know (that I've learned with previous side project) to ship a new side projects faster.
[1] https://erickhun.com/posts/why-you-should-have-a-side-projec...
[1] https://erickhun.com/posts/why-you-should-have-a-side-projec...
In my experience "Programming in a void is worthless" was the main factor to put the language aside and lose interest. Only learning for projects drove me all along through Node, Golang, C# and counting.
I went pretty wide on languages too. I kinda wish I spent that time learning more useful things though. It's certainly nice to be exposed to different language concepts, but I think there's too much conceptual overlap between e.g. C# and Golang for there to be that much benefit from it.
If I had to pick languages that changed my thinking the most, they would probably be: Haskell, Erlang, Clojure, Prolog, and R. Unique languages like Erlang/Elixir and Prolog can be "10x" languages - they were written for specific purposes and if your problem fits that purpose it will be much easier to solve than in most other languages.
If I had to pick languages that changed my thinking the most, they would probably be: Haskell, Erlang, Clojure, Prolog, and R. Unique languages like Erlang/Elixir and Prolog can be "10x" languages - they were written for specific purposes and if your problem fits that purpose it will be much easier to solve than in most other languages.
Same here, though I've been chugging along for 34 years. Used to write all kinds of software to try out new languages/ideas, but that all changed once I went down the rabbit hole of designing my own language. Since then, I've mostly been trying out different host languages, features and implementation techniques. I figure once I get to a point where the language is good enough, I'll go back to writing all kinds of software but in my own language. It really doesn't matter that much, the journey is the goal, you do whatever it takes to stay motivated and keep learning.
https://github.com/codr7/gfoo
https://github.com/codr7/gfoo
As someone, whose side project[1] graduated into a full-time company, I agree with a lot of stuff in this post -
> Lesson 0: Programming in a void is worthless
100% true. If you are trying to learn a language without a goal, you'll probably never graduate from tutorials. Imposing your own requirements/boundaries, just makes the learning part more engrossing and you'll make connections which you won't otherwise. Iterating as fast as possible is worthwile itself.
If you want to grow as a programmer even more, try to convert that side project into a paid one. It definitely changes your view of the world. As programmers, we want to see elegance in code but real life is messy. We want to separate the world of programming from the human life and sometimes for good reason. You might find satisfaction in writing pure code (and that's great) but there's an opposite world too which will humble the strong opinions within you. Haggling about microservices vs monoliths seems trivial in the grand scheme of things (the customer doesn't care!). I still debate about this with fellow devs but at the end of the day, I really don't get stressed about it. For me, programming is pretty much only about building solutions to existing problems which improves my or others lives. Everything else is just an opinion which will not be considered until its time is due.
> Lesson 2: Organizing my thoughts is important, but tricky to figure out
Agree. Especially difficult if the software doesn't structure the knowledge in the same way as we think. As a dev, I have never been satisfied with any specific solution. But don't fret honestly. It's unlikely that any given piece of software will work for all your cases. Always take the context into consideration. Plenty of times I work on paper if what I'm thinking doesn't go into a specific tool. Don't try to fit yourself into a box when your mind itself can't. That said, a mindmap (big picture) + a task manager (big picture broken down into specific tasks) + a note taking app (learnings + thoughts derived from completing specific tasks) covers most of my bases. For publicly available information, I store it in a tool of my own making[1]
[1] https://getliste.com
> Lesson 0: Programming in a void is worthless
100% true. If you are trying to learn a language without a goal, you'll probably never graduate from tutorials. Imposing your own requirements/boundaries, just makes the learning part more engrossing and you'll make connections which you won't otherwise. Iterating as fast as possible is worthwile itself.
If you want to grow as a programmer even more, try to convert that side project into a paid one. It definitely changes your view of the world. As programmers, we want to see elegance in code but real life is messy. We want to separate the world of programming from the human life and sometimes for good reason. You might find satisfaction in writing pure code (and that's great) but there's an opposite world too which will humble the strong opinions within you. Haggling about microservices vs monoliths seems trivial in the grand scheme of things (the customer doesn't care!). I still debate about this with fellow devs but at the end of the day, I really don't get stressed about it. For me, programming is pretty much only about building solutions to existing problems which improves my or others lives. Everything else is just an opinion which will not be considered until its time is due.
> Lesson 2: Organizing my thoughts is important, but tricky to figure out
Agree. Especially difficult if the software doesn't structure the knowledge in the same way as we think. As a dev, I have never been satisfied with any specific solution. But don't fret honestly. It's unlikely that any given piece of software will work for all your cases. Always take the context into consideration. Plenty of times I work on paper if what I'm thinking doesn't go into a specific tool. Don't try to fit yourself into a box when your mind itself can't. That said, a mindmap (big picture) + a task manager (big picture broken down into specific tasks) + a note taking app (learnings + thoughts derived from completing specific tasks) covers most of my bases. For publicly available information, I store it in a tool of my own making[1]
[1] https://getliste.com
Literally was thinking about building something to save articles. Liste looks beautiful, excited to see it in action.
Liste looks great! I've been looking around for a better tool to aid in note-taking after all the posts around this space over the last few weeks. Will keep an eye on it and good luck with the launch.
How did you decide to start a company around the idea before launch?
How did you decide to start a company around the idea before launch?
Thanks.
It was mostly a personal itch. I had been using Pocket for sometime but it honestly wasn't cutting it anymore. I built a smaller app over the Pocket api but as time progressed, the app diverged more and more. Once the Pocket api just became a glorified database, I decided to go all in. I waited for other solutions to come around but none were satisfying enough. After 5 years I had enough, talked to some people who expressed similar desire and that's when I jumped in full time.
It was mostly a personal itch. I had been using Pocket for sometime but it honestly wasn't cutting it anymore. I built a smaller app over the Pocket api but as time progressed, the app diverged more and more. Once the Pocket api just became a glorified database, I decided to go all in. I waited for other solutions to come around but none were satisfying enough. After 5 years I had enough, talked to some people who expressed similar desire and that's when I jumped in full time.
>> Most times, when I’ve tried to learn a programming technology without a concrete goal to get something built, it is hard for me to maintain interest
I feel the same way.
However, I take it one step further. I lose interest after I create the one core feature that drew me to the project. I've made shoot em ups before, but I wanted to do one with enemies that flew in like Galaga. After I replicated the first few patterns, I lost interest. You couldn't even shoot the enemies, but I already knew how to do that.
I feel the same way.
However, I take it one step further. I lose interest after I create the one core feature that drew me to the project. I've made shoot em ups before, but I wanted to do one with enemies that flew in like Galaga. After I replicated the first few patterns, I lost interest. You couldn't even shoot the enemies, but I already knew how to do that.
I've never had a side project lead to anything profitable in the monetary sense, but they've been very helpful in me getting great jobs.
I'm currently taking a side project and going to attempt to make a business out of it. As far as building it goes, it's basically the culmination of about 5 other side projects I did over the past couple years. So I've been able to build the MVP extremely quickly.
I totally get and appreciate the "don't code outside of work, have a life", but at least for me, side projects have been very valuable.
I'm currently taking a side project and going to attempt to make a business out of it. As far as building it goes, it's basically the culmination of about 5 other side projects I did over the past couple years. So I've been able to build the MVP extremely quickly.
I totally get and appreciate the "don't code outside of work, have a life", but at least for me, side projects have been very valuable.
Side projects are great. Not just for learning technology, but also for playing around with technology you already know.
It can be fun to built something without the 'overhead' of Sprints, standups, team meetings, design documents,.. :)
It can be fun to built something without the 'overhead' of Sprints, standups, team meetings, design documents,.. :)
Could not agree more. I kept playing with my side project of news aggregation [1] for almost three years and used only for my own consumption. Then few friends wanted to also use the site and then it just organically grew. And this project still is a side project although lot more people use it.
[1] https://embit.ca
[1] https://embit.ca
Yeah i totally agree with this, It's also great to reduce the complexity of what you're working on to get to the learning.
I've been writing some java stuff that doesn't use magic annotations and guess what, java's got fun again.
I love it how when a new situation comes up at work that I have encountered in my side projects, I can come up with some approaches, strengths and weaknesses pretty fast. It makes me look like I'm a lot more knowledgeable than I am.
Well but actually you are that knowledgeable - you just gained the knowledge through experience outside of work.
But you're right, it happened to me a few times as well and people assume you "just know". :P
But you're right, it happened to me a few times as well and people assume you "just know". :P
I'm one of these people that doesn't have much time less the energy to focus on side projects when I'm home from work, that said my career has been changing over the last few years and at times I rarely have any code to write at work.
These are the times when I really find a yearning to write something and I want to put a bit of time into a side project like learning Godot, or writing a desktop GUI based program with Rust.
I just need to be doing something different with my day job to have the inspiration and energy to code when I get home, unfortunately at the moment I'm coding at work again, and when I get home I will stare blankly at the screen infront of me if I try and write more code, even in a different language.
These are the times when I really find a yearning to write something and I want to put a bit of time into a side project like learning Godot, or writing a desktop GUI based program with Rust.
I just need to be doing something different with my day job to have the inspiration and energy to code when I get home, unfortunately at the moment I'm coding at work again, and when I get home I will stare blankly at the screen infront of me if I try and write more code, even in a different language.
(author here)
I definitely recognize that not everyone has the energy to code at home after a day of coding at work. Often, I don't either. Side projects are a varying thing for me. I do try to make sure what I do code gets documented in some fashion, however.
I definitely recognize that not everyone has the energy to code at home after a day of coding at work. Often, I don't either. Side projects are a varying thing for me. I do try to make sure what I do code gets documented in some fashion, however.
I can relate to the post, having just started for couple of months now, learning to write code for your self is satisfying. I have followed several youtube videos to learn programming language, but the fruitful results only come from working on side projects/challenges etc.
The only way to account my progress is through github commits. I love the color green. ;)
Would love to get feedback on my blog http://codingbbq.github.io. Cheers.
The only way to account my progress is through github commits. I love the color green. ;)
Would love to get feedback on my blog http://codingbbq.github.io. Cheers.
I agree you should have a real problem to solve when learning a new language. However, I'd temper expectations about the outcome.
Generally I find side projects are either about learning a new technology/language or making something that should exist, but not both. It's important to be clear which is the primary objective.
If the objective is to make something, pick the most familiar language and libraries, bang it out, and ship it. If the objective is to learn something, for sure pick a real project to focus your efforts, but understand it will take longer and the end result probably won't be amazing, though hopefully you'll learn a lot in the process.
Generally I find side projects are either about learning a new technology/language or making something that should exist, but not both. It's important to be clear which is the primary objective.
If the objective is to make something, pick the most familiar language and libraries, bang it out, and ship it. If the objective is to learn something, for sure pick a real project to focus your efforts, but understand it will take longer and the end result probably won't be amazing, though hopefully you'll learn a lot in the process.
I put all my notes and bookmarks in my self-hosted bookmarking site https://github.com/jonschoning/espial . I definitely agree with the author that the combo of tags, search, the feed, and notes is very effective technique that I sure every day.
In Haskell and Elm! Nice project. I did not see any code "shared" (or Elm generated from the Haskell code) to enforce type-safety across the network barrier. Afaik there are a few projects that could help with this. Not saying you need this (small project, easy to manage) but it's very sweet to have type safety from db, through BE app layer, though the wire format, all the way to the FE model code.
>The nice thing about the Go/Lua journal is that it’s far more flexible than the C# version, due to being able to write pages in Lua. Which means I’ll be able to
To what?!?! D:
To what?!?! D:
I don't know exactly what I was thinking when I wrote the article, but, here's the best fix I think I can add (article edited to include it):
> Which means I’ll be able to use it for more things, and hopefully get that tight feedback loop back in place.
> Which means I’ll be able to use it for more things, and hopefully get that tight feedback loop back in place.
> Lesson 0: Programming in a void is worthless
I wouldn't say worthless, but there's a world of difference whenever you have a practical use (or someone else's use). It forces your brain to focus and go broader at the same time.
I wouldn't say worthless, but there's a world of difference whenever you have a practical use (or someone else's use). It forces your brain to focus and go broader at the same time.
What my years of side projects have taught me:
* At work its better to hurry than get anything done.
Regardless of language if you work for a company of greater than 1000 people there is a certain nearly identical way of doing things. This way of doing things is based upon a combination user platform, quantity of developers on the market with a particular skill, and a need to pretend to be busy even when you don't actually accomplish anything. In most of my experience the platform was the web and the language of choice was Java (even though Java is not a web technology).
When you are working on side projects there are only two goals: don't waste your own time and produce something of value. Nothing else matters. And so you learn to become very productive and extremely focused on what you ship to production, because you would rather be playing games or drinking a beer than pretending to be busy.
The corporate world doesn't work like this. Everybody is paid a salary exchange for 45 hours of your life each week and your assignments are generally governed by an agile sprint cycle, so there is absolutely no motivation to be productive. Maybe if you work twice as hard your bonus will be 5-10% bigger. Maybe if you deliver code that is perfect in that it never requires maintenance and never churns defects you can spend more time reading about foreign places on Wikipedia.
Frustration sets in after watching the corporate approach continuously releasing defective code into production because its important to hurry instead of write things down or write the code correctly the first time. You could always suggest a better way of doing things, but since there is no motivation to do things better all you are really accomplishing is frustrating other people.
* At work don't reinvent the wheel (if somebody/something is capable of doing your job then let them do your job)
When you are working on side projects there is nobody there to do the heavy lifting for you. You can figure it out or it simply isn't important enough to get done. It's the same way with risks and product performance. People who haven't spent time on personal projects or with equity at a start up have no motivation to try harder. That is why there are giant frameworks and a couple 1000 open source packages in your corporate application to solve simple common problems developers are unwilling to solve themselves. Nobody working on a public personal project will build around something like the 1000 ton hammer of the gods that is Angular or Sprint MVC, but you will certainly find these in public facing enterprise applications where developers have no care about punishing their users in exchange for easy.
* You are more productive not doing work
A tremendous part of writing software is the cognitive thinking that occurs away from the keyboard. This could be planning, brainstorming a new feature, reflecting on a past feature, or putting things together in a new way to envision defects or refactoring opportunities. That said, its more valuable to work really hard to accomplish a feature or solve for a defect and then back off from the computer. You haven't stopped thinking about the application, but now you are thinking about the experience or new ways of doing things that you would never think about purely looking at the code. In the corporate world you are extremely lucky to find documentation much less anything like planning or feature engagement from the developers.
* At work its better to hurry than get anything done.
Regardless of language if you work for a company of greater than 1000 people there is a certain nearly identical way of doing things. This way of doing things is based upon a combination user platform, quantity of developers on the market with a particular skill, and a need to pretend to be busy even when you don't actually accomplish anything. In most of my experience the platform was the web and the language of choice was Java (even though Java is not a web technology).
When you are working on side projects there are only two goals: don't waste your own time and produce something of value. Nothing else matters. And so you learn to become very productive and extremely focused on what you ship to production, because you would rather be playing games or drinking a beer than pretending to be busy.
The corporate world doesn't work like this. Everybody is paid a salary exchange for 45 hours of your life each week and your assignments are generally governed by an agile sprint cycle, so there is absolutely no motivation to be productive. Maybe if you work twice as hard your bonus will be 5-10% bigger. Maybe if you deliver code that is perfect in that it never requires maintenance and never churns defects you can spend more time reading about foreign places on Wikipedia.
Frustration sets in after watching the corporate approach continuously releasing defective code into production because its important to hurry instead of write things down or write the code correctly the first time. You could always suggest a better way of doing things, but since there is no motivation to do things better all you are really accomplishing is frustrating other people.
* At work don't reinvent the wheel (if somebody/something is capable of doing your job then let them do your job)
When you are working on side projects there is nobody there to do the heavy lifting for you. You can figure it out or it simply isn't important enough to get done. It's the same way with risks and product performance. People who haven't spent time on personal projects or with equity at a start up have no motivation to try harder. That is why there are giant frameworks and a couple 1000 open source packages in your corporate application to solve simple common problems developers are unwilling to solve themselves. Nobody working on a public personal project will build around something like the 1000 ton hammer of the gods that is Angular or Sprint MVC, but you will certainly find these in public facing enterprise applications where developers have no care about punishing their users in exchange for easy.
* You are more productive not doing work
A tremendous part of writing software is the cognitive thinking that occurs away from the keyboard. This could be planning, brainstorming a new feature, reflecting on a past feature, or putting things together in a new way to envision defects or refactoring opportunities. That said, its more valuable to work really hard to accomplish a feature or solve for a defect and then back off from the computer. You haven't stopped thinking about the application, but now you are thinking about the experience or new ways of doing things that you would never think about purely looking at the code. In the corporate world you are extremely lucky to find documentation much less anything like planning or feature engagement from the developers.
When I was doing programming competitions, the most valuable advice I was given was to print out the problem set and then walk away from the computer for the first hour of the competition. This skill was even more important for the four-people-one-computer challenges, where you have to be able to design, implement, test, and debug your code without the crutch of a computer to be productive.
This advice I consider to be the most valuable programming advice I have ever received.
Code can be a distraction from the process of coding. It is way too easy to got lost in the minutiae of how things are to be implemented and delude yourself into believing you are making progress when you don't know what you are doing. The saga of the Sudoku solver [1] is a pretty well-known example: the coder in question spent an awful lot of time redesigning the implementation of the game board because he didn't know how to actually solve anything, and yet changing the implementation looks like progress without making any steps on the actual problem.
[1] See http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... for mention of it.
This advice I consider to be the most valuable programming advice I have ever received.
Code can be a distraction from the process of coding. It is way too easy to got lost in the minutiae of how things are to be implemented and delude yourself into believing you are making progress when you don't know what you are doing. The saga of the Sudoku solver [1] is a pretty well-known example: the coder in question spent an awful lot of time redesigning the implementation of the game board because he didn't know how to actually solve anything, and yet changing the implementation looks like progress without making any steps on the actual problem.
[1] See http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... for mention of it.
I guess it does create perverse incentives. If you look busy and making progress, it is easier to justify to upper management on what you are doing.
I’ve felt those frustrations one too many times myself. One thing I learned though is that there’s a reason and method to the madness.
The people that do the decisions and prioritizations are usually just as smart as developers, but have different priorities.
It’s often more lucrative for a company to release something early even if it’s beta quality, since business knowledge is a very lucrative commodity. The company will know more about its customers, how it can help (or exploit) them better.
And things get more complicated when you have multiple teams. Yeah you can spend a sprint or two to polish things now and save yourself 4-5 sprints worth in the future. But if there are 4 more teams waiting on your deliverables, it might be a worthwhile trade for the company as a whole.
Understanding where your own team fits inside the huge structure of a big company is of course the PM’s job, so you as a dev don’t have to know about it. But thats a lot tougher than figuring out estimates is for us, and even more disruptive if gotten wrong.
Estimating a dev task deals with a lot of unknowns. Building a sequence of tasks for teams to follow takes _those_ as input and needs to produce something thats not just pure chance. I don’t envy that one bit.
Once I started to get the bigger picture into account myself as a dev, it became much easier to go along with those decisions and to know when I can push for good quality stuff and where to leave it be.
It’s the whole “let me help you achieve your goals so you can help me achieve mine” thing and has made my life as a dev much more pleasant.
The people that do the decisions and prioritizations are usually just as smart as developers, but have different priorities.
It’s often more lucrative for a company to release something early even if it’s beta quality, since business knowledge is a very lucrative commodity. The company will know more about its customers, how it can help (or exploit) them better.
And things get more complicated when you have multiple teams. Yeah you can spend a sprint or two to polish things now and save yourself 4-5 sprints worth in the future. But if there are 4 more teams waiting on your deliverables, it might be a worthwhile trade for the company as a whole.
Understanding where your own team fits inside the huge structure of a big company is of course the PM’s job, so you as a dev don’t have to know about it. But thats a lot tougher than figuring out estimates is for us, and even more disruptive if gotten wrong.
Estimating a dev task deals with a lot of unknowns. Building a sequence of tasks for teams to follow takes _those_ as input and needs to produce something thats not just pure chance. I don’t envy that one bit.
Once I started to get the bigger picture into account myself as a dev, it became much easier to go along with those decisions and to know when I can push for good quality stuff and where to leave it be.
It’s the whole “let me help you achieve your goals so you can help me achieve mine” thing and has made my life as a dev much more pleasant.
> The corporate world doesn't work like this. Everybody is paid a salary exchange for 45 hours of your life each week and your assignments are generally governed by an agile sprint cycle, so there is absolutely no motivation to be productive.
I’ve consulted in a lot of large enterprises, and this is really untrue. If you’re happy just stagnating and some level that you’ve decided is good enough, you can get away with it for a while. But such people absolutely don’t develop their careers. They’ll probably get small raises every year, and perhaps the occasional promotion based on years served. But that’s really as good as it gets for them. You also can’t do it forever. Most of the time when I go into a new organisation, I find groups of these people. They’re usually very friendly to work with, but they’ll have skills that are 10-20 years out of date, and mediocre at that. Eventually even the slow moving large organisations start to outpace their own personal development, and they get left looking for jobs that don’t really exist anymore. I worked with a guy a few years ago, and all he’d ever really done was Swing projects. He added me on LinkedIn a few months ago, he’s been working at a cinema for the past two years, trying to find a new Swing project to work on.
I’ve consulted in a lot of large enterprises, and this is really untrue. If you’re happy just stagnating and some level that you’ve decided is good enough, you can get away with it for a while. But such people absolutely don’t develop their careers. They’ll probably get small raises every year, and perhaps the occasional promotion based on years served. But that’s really as good as it gets for them. You also can’t do it forever. Most of the time when I go into a new organisation, I find groups of these people. They’re usually very friendly to work with, but they’ll have skills that are 10-20 years out of date, and mediocre at that. Eventually even the slow moving large organisations start to outpace their own personal development, and they get left looking for jobs that don’t really exist anymore. I worked with a guy a few years ago, and all he’d ever really done was Swing projects. He added me on LinkedIn a few months ago, he’s been working at a cinema for the past two years, trying to find a new Swing project to work on.
> But such people absolutely don’t develop their careers.
Given the choice what is better: developing your career or your skills/competencies?
Many developers learn some tool or giant framework instead of actually learning to write code or how to do their jobs because they are in a hurry to develop their careers. I would rather work with competent people who are less in a hurry to artificially justify their existence.
As an example in the real world nobody advertises their experience with a screwdriver, but the opposite is true in software. People will frequently advertise their limited value as a React or Angular developer. It’s clear they know how to use a tool, but can’t write an application to save their lives (or careers). Why should I not find that frustrating, particularly when these giant framework applications suck and these developers are immediately hostile to original code?
In that kind of work culture I could be 10x more productive, but if it’s met with hostility and not rewarded what’s my motivation to do anything more than be barely awake?
Given the choice what is better: developing your career or your skills/competencies?
Many developers learn some tool or giant framework instead of actually learning to write code or how to do their jobs because they are in a hurry to develop their careers. I would rather work with competent people who are less in a hurry to artificially justify their existence.
As an example in the real world nobody advertises their experience with a screwdriver, but the opposite is true in software. People will frequently advertise their limited value as a React or Angular developer. It’s clear they know how to use a tool, but can’t write an application to save their lives (or careers). Why should I not find that frustrating, particularly when these giant framework applications suck and these developers are immediately hostile to original code?
In that kind of work culture I could be 10x more productive, but if it’s met with hostility and not rewarded what’s my motivation to do anything more than be barely awake?
> developing your career or your skills/competencies?
GP was saying that you only develop your career by developing skills. React is a skill, so is Angular, so is the wide world of front-end web programming.
GP was saying that you only develop your career by developing skills. React is a skill, so is Angular, so is the wide world of front-end web programming.
I disagree those are tools, like an grossly enormous hammer. If you had learned data structures, the DOM, storage, and all the other things that comprise the platform your opinions of the available tools would change. Nobody else in the world immediately jumps to nuclear weapons as their first stage tool. Only in software do we immediately jump to the nuclear option for all tasks, and there is something wrong with that.
> data structures, the DOM, storage, and all the other things that comprise the platform your opinions of the available tools would change
I do know all of those things. I still think React, Angular and other frontend frameworks have a time and place.
I do know all of those things. I still think React, Angular and other frontend frameworks have a time and place.
You're describing the opposite extreme. Most people are aware that they need to strike a balance: be aware of your own marketability versus just doing enough but not burning themselves up.
Being more or less productive is defined by - in no particular order - your salary, workplace culture (a due sense of agency and feeling respected,...), your own intrinsic motivation to choose a particular career path and personal circumstances that keep one at a job (usually household debt in any way shape or form).
Contrast that with the fact that digital tech today is an industry in which a large part of your toolbox and knowledge is perceived as "obsolete" within a short time (1 or 2 years). The net result is that most people burn themselves out in a race they can't hope to ever finish.
So the notion that "you must keep up at all costs" is unsustainable to put it mildly.
> They’ll probably get small raises every year, and perhaps the occasional promotion based on years served. But that’s really as good as it gets for them.
And that's totally valid. Why do people need to forcefully "climb the ladder" through promotions? A promotion isn't just a reward, it's often a serious career change that comes with serious challenges.
If someone wants to move vertically in a particular role throughout their career - say, as a developer - then that's totally fine too.
If someone isn't interested in spending time at home working on OSS projects - even when their employer provides incentives - then that's fine as well.
> They’re usually very friendly to work with, but they’ll have skills that are 10-20 years out of date, and mediocre at that. Eventually even the slow moving large organisations start to outpace their own personal development, and they get left looking for jobs that don’t really exist anymore.
That's a bias. Not every large organisation operates like a silicon valley style start up. Not every organisation has "building cutting-edge software" as a primary mission.
Banks, airlines, public institutions,... don't operate on short timescales (5 or 10 years), they operate on long timescales (20 to 50 years out). They aren't interested in shiny tech, they are interested in robust & proven solutions that last a very long time.
A large chunk of software engineering is boring and slow moving for a good reason: because breaking things comes with serious real world consequences.
Case in point: there's still demand for COBOL and Perl programmers. You can perfectly build a career in as an expert in those areas.
> I worked with a guy a few years ago, and all he’d ever really done was Swing projects. He added me on LinkedIn a few months ago, he’s been working at a cinema for the past two years, trying to find a new Swing project to work on.
Anecdotal.
If he works at a cinema, that might be because he can't simply move to another area with more swing projects (family or other concerns), or because he genuinely got tired and wanted something else, or because he just doesn't know how to promote himself properly - it's not his strong suit - and he turned to LinkedIn just recently.
Unless this is a close friend, you do not know half of this person's life and their decisions. Assuming x because y, well, that's just jumping to conclusions, isn't it then?
Being more or less productive is defined by - in no particular order - your salary, workplace culture (a due sense of agency and feeling respected,...), your own intrinsic motivation to choose a particular career path and personal circumstances that keep one at a job (usually household debt in any way shape or form).
Contrast that with the fact that digital tech today is an industry in which a large part of your toolbox and knowledge is perceived as "obsolete" within a short time (1 or 2 years). The net result is that most people burn themselves out in a race they can't hope to ever finish.
So the notion that "you must keep up at all costs" is unsustainable to put it mildly.
> They’ll probably get small raises every year, and perhaps the occasional promotion based on years served. But that’s really as good as it gets for them.
And that's totally valid. Why do people need to forcefully "climb the ladder" through promotions? A promotion isn't just a reward, it's often a serious career change that comes with serious challenges.
If someone wants to move vertically in a particular role throughout their career - say, as a developer - then that's totally fine too.
If someone isn't interested in spending time at home working on OSS projects - even when their employer provides incentives - then that's fine as well.
> They’re usually very friendly to work with, but they’ll have skills that are 10-20 years out of date, and mediocre at that. Eventually even the slow moving large organisations start to outpace their own personal development, and they get left looking for jobs that don’t really exist anymore.
That's a bias. Not every large organisation operates like a silicon valley style start up. Not every organisation has "building cutting-edge software" as a primary mission.
Banks, airlines, public institutions,... don't operate on short timescales (5 or 10 years), they operate on long timescales (20 to 50 years out). They aren't interested in shiny tech, they are interested in robust & proven solutions that last a very long time.
A large chunk of software engineering is boring and slow moving for a good reason: because breaking things comes with serious real world consequences.
Case in point: there's still demand for COBOL and Perl programmers. You can perfectly build a career in as an expert in those areas.
> I worked with a guy a few years ago, and all he’d ever really done was Swing projects. He added me on LinkedIn a few months ago, he’s been working at a cinema for the past two years, trying to find a new Swing project to work on.
Anecdotal.
If he works at a cinema, that might be because he can't simply move to another area with more swing projects (family or other concerns), or because he genuinely got tired and wanted something else, or because he just doesn't know how to promote himself properly - it's not his strong suit - and he turned to LinkedIn just recently.
Unless this is a close friend, you do not know half of this person's life and their decisions. Assuming x because y, well, that's just jumping to conclusions, isn't it then?
> You're describing the opposite extreme.
No, I’m simply debunking the parent commenter’s assertion that “there is absolutely no motivation to be productive”.
> a large part of your toolbox and knowledge is perceived as "obsolete" within a short time (1 or 2 years)
This is a major exaggeration. I do a fair number of node projects. I did my first one ~8 years ago. I don’t think I’m close to doing my last one, and it hasn’t been hard to keep up with the changes in that time.
> Banks, airlines, public institutions,... don't operate on short timescales (5 or 10 years), they operate on long timescales (20 to 50 years out). They aren't interested in shiny tech
I feel like you haven’t worked in a bank or airline before. Most of them have ancient tech in their core infrastructure, but a) they’re not happy about that, they just don’t know how to change it and b) a vast majority of their technical workforce will have no contact with that at all. Your average sized bank will typically employ 0 DB2 DBAs (they’ll all just be contracted from IBM), and a very small team of Cobol devs. You could work writing code in a bank for 10 years and never meet one. Banks and airlines are constantly trying to modernize (especially since they’ve realized how much money they can save by employing SREs/DevOps engineers). They love shiny new tech. A large portion of my consulting work comes from such organisations that are highly motivated to implement it.
> there's still demand for COBOL and Perl programmers. You can perfectly build a career in as an expert in those areas.
No you can’t. Today’s COBOL engineers are the ones that survived getting laid off when banks decided they didn’t want to invest in COBOL anymore. There’s essentially no entry level COBOL jobs on the market today.
> you do not know half of this person's life and their decisions
I know he got laid off, and that he’s been looking for work since then. I also know his skill set is no longer in particularly high demand. I see this happen all the time. A significant portion of my work comes from large organisations seeking to modernize their technical capabilities. They tend to be filled with people like him when I start, and a non-trivial portion of them tend to be gone a year later (all of the ones who couldn’t adapt to the new technology).
> might be because he can't simply move to another area with more swing projects
There is really no such place. There are still companies that use technology like that, but the number of them is shrinking every year, and people aren’t using it for new projects.
The bottom line is that even in large inefficient organisations, there is still a strong incentive to be productive and to invest in developing your own skills. Most people expect their careers to last 45+ years. Even if it takes 10 years for your skills to become obsolete in a slow moving organisation, you’d still have to spend the first 35 of those years developing your skills.
No, I’m simply debunking the parent commenter’s assertion that “there is absolutely no motivation to be productive”.
> a large part of your toolbox and knowledge is perceived as "obsolete" within a short time (1 or 2 years)
This is a major exaggeration. I do a fair number of node projects. I did my first one ~8 years ago. I don’t think I’m close to doing my last one, and it hasn’t been hard to keep up with the changes in that time.
> Banks, airlines, public institutions,... don't operate on short timescales (5 or 10 years), they operate on long timescales (20 to 50 years out). They aren't interested in shiny tech
I feel like you haven’t worked in a bank or airline before. Most of them have ancient tech in their core infrastructure, but a) they’re not happy about that, they just don’t know how to change it and b) a vast majority of their technical workforce will have no contact with that at all. Your average sized bank will typically employ 0 DB2 DBAs (they’ll all just be contracted from IBM), and a very small team of Cobol devs. You could work writing code in a bank for 10 years and never meet one. Banks and airlines are constantly trying to modernize (especially since they’ve realized how much money they can save by employing SREs/DevOps engineers). They love shiny new tech. A large portion of my consulting work comes from such organisations that are highly motivated to implement it.
> there's still demand for COBOL and Perl programmers. You can perfectly build a career in as an expert in those areas.
No you can’t. Today’s COBOL engineers are the ones that survived getting laid off when banks decided they didn’t want to invest in COBOL anymore. There’s essentially no entry level COBOL jobs on the market today.
> you do not know half of this person's life and their decisions
I know he got laid off, and that he’s been looking for work since then. I also know his skill set is no longer in particularly high demand. I see this happen all the time. A significant portion of my work comes from large organisations seeking to modernize their technical capabilities. They tend to be filled with people like him when I start, and a non-trivial portion of them tend to be gone a year later (all of the ones who couldn’t adapt to the new technology).
> might be because he can't simply move to another area with more swing projects
There is really no such place. There are still companies that use technology like that, but the number of them is shrinking every year, and people aren’t using it for new projects.
The bottom line is that even in large inefficient organisations, there is still a strong incentive to be productive and to invest in developing your own skills. Most people expect their careers to last 45+ years. Even if it takes 10 years for your skills to become obsolete in a slow moving organisation, you’d still have to spend the first 35 of those years developing your skills.
> it hasn’t been hard to keep up with the changes in that time.
That depends entirely on your context. Debt, disability, dependents, other personal goals,...
Not everyone can easily spend nights and weekends following what goes on in the JavaScript, Go and IoT space at the same time.
> a) they’re not happy about that, they just don’t know how to change it
It's called "opportunity cost" and "risk management". They rather stick with what works - the best of all the worse alternatives - instead of stepping into the unknown. Personal happiness on the part of the staff is subservient to that strategy.
Don't confuse the opinions of the tech staff with the mindset upstairs.
> b) a vast majority of their technical workforce will have no contact with that at all.
Goes without saying.
> Cobol devs
I choose COBOL and Perl as random examples of niches. There is tons of legacy infrastructure to be maintained beyond COBOL and Perl as well.
> They love shiny new tech. A large portion of my consulting work comes from such organisations that are highly motivated to implement it.
Of course they do. But shiny tech only gets to be implemented in place where failure is factored against the potential gains.
Put differently, a mobile app being unresponsive for 15 minutes is an annoyance. Banking or medical records getting corrupted or lost, is a disaster that simply can't ever happen.
> A significant portion of my work comes from large organisations seeking to modernize their technical capabilities. They tend to be filled with people like him when I start, and a non-trivial portion of them tend to be gone a year later (all of the ones who couldn’t adapt to the new technology).
That's bad management based on short-term thinking, and it has absolutely nothing to do with technical skills.
Modernization isn't about the tech, it's about reducing costs. Employees are seen as a liability. Always. And so lay-offs and modernization go hand in hand. The hidden cost is the loss of institutional knowledge and culture.
Instead, they try to cheap out by bringing in consultants, like you, to do work on a per-project basis. But that doesn't create any institutional knowledge. Instead, it makes them utterly dependent on the volatility of the consultancy market.
Down the line, what you get are stories like the trainwreck which is Boeing.
Even if those employees did spend time learning Node in their free time, they would still have lost their jobs. Simply because their salaries, and the protections & benefits that salaried employers enjoy, made them unattractive.
And those who did learn, well, they left long before the writing was on the wall anyway, because the only reason reason to invest time and effort in your own skills is for your own sake, not the sake of your employer.
Finally, working for yourself, or working as an outplaced resource comes with many drawbacks. It may work out fine if you are healthy and you're in a situation that allows you to do that type of work. But those conditions can change at any time.
Private corporations and enterprises aren't charity. It's sensible to reduce costs as you go in order to stay competitive. But when corporations do that in such a way that the labour markets get stiffled, income levels stagnate or decrease and the fabric of society gets pressured, well, that's just predatory capitalism.
If you can live in such an environment, then that's great for you. But judging others because they struggle? That's a hard nope right there.
That depends entirely on your context. Debt, disability, dependents, other personal goals,...
Not everyone can easily spend nights and weekends following what goes on in the JavaScript, Go and IoT space at the same time.
> a) they’re not happy about that, they just don’t know how to change it
It's called "opportunity cost" and "risk management". They rather stick with what works - the best of all the worse alternatives - instead of stepping into the unknown. Personal happiness on the part of the staff is subservient to that strategy.
Don't confuse the opinions of the tech staff with the mindset upstairs.
> b) a vast majority of their technical workforce will have no contact with that at all.
Goes without saying.
> Cobol devs
I choose COBOL and Perl as random examples of niches. There is tons of legacy infrastructure to be maintained beyond COBOL and Perl as well.
> They love shiny new tech. A large portion of my consulting work comes from such organisations that are highly motivated to implement it.
Of course they do. But shiny tech only gets to be implemented in place where failure is factored against the potential gains.
Put differently, a mobile app being unresponsive for 15 minutes is an annoyance. Banking or medical records getting corrupted or lost, is a disaster that simply can't ever happen.
> A significant portion of my work comes from large organisations seeking to modernize their technical capabilities. They tend to be filled with people like him when I start, and a non-trivial portion of them tend to be gone a year later (all of the ones who couldn’t adapt to the new technology).
That's bad management based on short-term thinking, and it has absolutely nothing to do with technical skills.
Modernization isn't about the tech, it's about reducing costs. Employees are seen as a liability. Always. And so lay-offs and modernization go hand in hand. The hidden cost is the loss of institutional knowledge and culture.
Instead, they try to cheap out by bringing in consultants, like you, to do work on a per-project basis. But that doesn't create any institutional knowledge. Instead, it makes them utterly dependent on the volatility of the consultancy market.
Down the line, what you get are stories like the trainwreck which is Boeing.
Even if those employees did spend time learning Node in their free time, they would still have lost their jobs. Simply because their salaries, and the protections & benefits that salaried employers enjoy, made them unattractive.
And those who did learn, well, they left long before the writing was on the wall anyway, because the only reason reason to invest time and effort in your own skills is for your own sake, not the sake of your employer.
Finally, working for yourself, or working as an outplaced resource comes with many drawbacks. It may work out fine if you are healthy and you're in a situation that allows you to do that type of work. But those conditions can change at any time.
Private corporations and enterprises aren't charity. It's sensible to reduce costs as you go in order to stay competitive. But when corporations do that in such a way that the labour markets get stiffled, income levels stagnate or decrease and the fabric of society gets pressured, well, that's just predatory capitalism.
If you can live in such an environment, then that's great for you. But judging others because they struggle? That's a hard nope right there.
> A tremendous part of writing software is the cognitive thinking that occurs away from the keyboard.
This is true because, you must create the program of how the computer and the user will interact. You must program the computer and program the user, their interaction.
There are always many different ways to do that. And the choice, or invention of how that happens really determines much of the success of the product.
It has to be easy and intuitive for people to use the app yet empower them to accomplish great things. That is no small feat and it is the most important one.
This is true because, you must create the program of how the computer and the user will interact. You must program the computer and program the user, their interaction.
There are always many different ways to do that. And the choice, or invention of how that happens really determines much of the success of the product.
It has to be easy and intuitive for people to use the app yet empower them to accomplish great things. That is no small feat and it is the most important one.
This is all really, really good advice. I wish I could read this, and understood it, and the surrounding context, ten years ago.
I am stuck in the same loop of trying to find the best way to organise my thoughts. My best attempt was using Dropbox Paper. They have a great editing/writing experience, but eventually it got to a stage where the page load times took too long.
I'm currently trying out vimwiki. Let's see how that goes.
I'm currently trying out vimwiki. Let's see how that goes.
I've let go of my addiction to finding the best tool and settled on Emacs+Org-Mode (specifically with Spacemacs so I can use Vim keybindings).
Over the years I've tried so many tools, languages, workflows, and the only ones that stuck were the ones that were boring but timeless. I've not just been gravitating toward OrgMode for all my note keeping, but I've also gotten more and more into bash for much of my stuff.
There are downsides to that, of course. It's frustrating that I'm mostly limited to text-only things, for example. But it feels like any investment into bash/emacs+orgmode/emacs+tramp/emacs+? offers so much more than becoming reliant on app number <x> that quite possibly disappears or stagnates.
Over the years I've tried so many tools, languages, workflows, and the only ones that stuck were the ones that were boring but timeless. I've not just been gravitating toward OrgMode for all my note keeping, but I've also gotten more and more into bash for much of my stuff.
There are downsides to that, of course. It's frustrating that I'm mostly limited to text-only things, for example. But it feels like any investment into bash/emacs+orgmode/emacs+tramp/emacs+? offers so much more than becoming reliant on app number <x> that quite possibly disappears or stagnates.
> bash/emacs+orgmode/emacs+tramp/emacs+?
You wanted to say "Magit" in the last one :-)
Why do you say you're limited to text-only things? Org supports links, images, code blocks, spreadsheet-like tables and such. For me the experience of migrating to Emacs+Org was more of a liberating type.
Why do you say you're limited to text-only things? Org supports links, images, code blocks, spreadsheet-like tables and such. For me the experience of migrating to Emacs+Org was more of a liberating type.
Ah yes, Magit is still on my list of Emacs things to learn :).
I had the same, but recently I just created my own personal site for my notes. The main benefit that I did not expect is that, in theory, everyone can see it. This causes me to put more work into a note:
* To make sure that it actually is correct. Multiple times I discovered when reading the documentation that I only had guessed it sort of right and that there were some key bits of info that I had missed.
* To make sure that it is complete and that it gives just enough background information for those who want to use it without being in the exact situation that I was in. I.e. for myself in a couple of weeks/months.
There are more benefits. Like being able to structure it exactly the way you like it with links, tags, search, etc. And that you can show it casually to potential employers, who won't read a letter of it, but they can see that you actually put in work and understand some topics. This last point can also work for friends and colleagues.
* To make sure that it actually is correct. Multiple times I discovered when reading the documentation that I only had guessed it sort of right and that there were some key bits of info that I had missed.
* To make sure that it is complete and that it gives just enough background information for those who want to use it without being in the exact situation that I was in. I.e. for myself in a couple of weeks/months.
There are more benefits. Like being able to structure it exactly the way you like it with links, tags, search, etc. And that you can show it casually to potential employers, who won't read a letter of it, but they can see that you actually put in work and understand some topics. This last point can also work for friends and colleagues.
I've been trying out vimwiki for work of late, so far it's been going well for helping me process things.
In a quest to find ways to manage my focus, I've also taken up doodling. It's proven to be a good way to help keep me from falling down internet rabbit holes nearly as badly as I used to.
In a quest to find ways to manage my focus, I've also taken up doodling. It's proven to be a good way to help keep me from falling down internet rabbit holes nearly as badly as I used to.
I can suggest Dynalist
Check out Notion (https://www.notion.so/product), it's really smooth to use and loads fast
> Lesson 3: Search is a great tool for debugging and flexible organization
"Give me modularity or give me grep!"
That saying was intended to showcase the importance of modularity, with the idea that you shouldn't need to grep good code. But my personal experience is that if you have to choose, grep wins, no contest.
"Give me modularity or give me grep!"
That saying was intended to showcase the importance of modularity, with the idea that you shouldn't need to grep good code. But my personal experience is that if you have to choose, grep wins, no contest.
Slightly related. Here is a side project I wrote to keep track of the tons of information I've read about or _might want_ to read about one day, which kind of overlaps with the journal app that was described: https://digraph.app/.
Information is different than knowledge, and part of the challenge of acquiring knowledge is being able to get back to information you know you've seen in the past if it seems relevant to something in front of you right now.
Information is different than knowledge, and part of the challenge of acquiring knowledge is being able to get back to information you know you've seen in the past if it seems relevant to something in front of you right now.
This is good advice. I've been working on a side project for almost a year now [1]. It's a constant struggle with the pressure to reach a certain amount of users or impact, when at the end of the day I've just been building it to scratch my own itch. This article is a helpful reminder of that.
[1] https://encore.dev
[1] https://encore.dev
Very true. I followed the same path, and a side project was always the way to learn something new. Sometimes those side projects become full on ventures as well. Added bonus.
I also very well remember my joy after I "invented" the AMQ, only to later find out about ActiveMQ, RabbitMQ etc. (which didn't diminish that "proud" feeling)
I also very well remember my joy after I "invented" the AMQ, only to later find out about ActiveMQ, RabbitMQ etc. (which didn't diminish that "proud" feeling)
I think that is some of the best validation, to know that your solution is not to different than the ‘standard’, without having any prior knowledge of its existence.
Good work!
Good work!
Excellent advice.
And starting with #0 adds street cred.
And starting with #0 adds street cred.
I like your blog's style and color. Do you have a blog dedicated to building it? Thanks
I don't at the moment, though I could write one up at some point.
The short answer, though, is that I knew I wanted green in the color scheme (due to having grown up in the tropics), and I liked how James Hague did his blog https://prog21.dadgum.com/
The rest was just iterating on that.
The short answer, though, is that I knew I wanted green in the color scheme (due to having grown up in the tropics), and I liked how James Hague did his blog https://prog21.dadgum.com/
The rest was just iterating on that.
Thanks, I really enjoyed the theme.
In my career (granted not a long one, but made it to C-Level in a startup after about 5-7 years) I've always used them to show my interest and learning skill to do something. It didn't matter whether it had 1 user or 1 million, employers were always very impressed and it always gives you an advantage during interviewing. Most of those have also been with very little or no code at all.
I'm normally prioritising people with side projects in the recruiting process vs. people who only did school -> work