For those who feel like a side project needs to be successful or reach a certain amount of revenue/lines of code/users to be successful in your eyes: Don't feel pressured.
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
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.
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'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.
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.
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.
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.
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]
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?
>> 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'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.
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.
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.
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.
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. ;)
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.
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
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.
* 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.
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 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.
> 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.
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'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.
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.
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.
> 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.
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.
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.
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 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.
[+] [-] freshfey|6 years ago|reply
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
[+] [-] alexpetralia|6 years ago|reply
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.
[+] [-] mkane848|6 years ago|reply
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.
[+] [-] michaelbuckbee|6 years ago|reply
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.
[+] [-] eric_khun|6 years ago|reply
[1] https://erickhun.com/posts/why-you-should-have-a-side-projec...
[+] [-] alithejumbo|6 years ago|reply
[+] [-] codr7|6 years ago|reply
https://github.com/codr7/gfoo
[+] [-] inapis|6 years ago|reply
> 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
[+] [-] ssamkough|6 years ago|reply
[+] [-] eandre|6 years ago|reply
How did you decide to start a company around the idea before launch?
[+] [-] rofrol|6 years ago|reply
saved serches -> saved searches
[+] [-] bluedino|6 years ago|reply
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.
[+] [-] city41|6 years ago|reply
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.
[+] [-] Insanity|6 years ago|reply
It can be fun to built something without the 'overhead' of Sprints, standups, team meetings, design documents,.. :)
[+] [-] embit|6 years ago|reply
[1] https://embit.ca
[+] [-] gonzo41|6 years ago|reply
[+] [-] ThalesX|6 years ago|reply
[+] [-] Blaiz0r|6 years ago|reply
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.
[+] [-] yumaikas|6 years ago|reply
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.
[+] [-] codingbbq|6 years ago|reply
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.
[+] [-] mmahemoff|6 years ago|reply
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.
[+] [-] platz|6 years ago|reply
[+] [-] cies|6 years ago|reply
[+] [-] shrimp_emoji|6 years ago|reply
To what?!?! D:
[+] [-] yumaikas|6 years ago|reply
> Which means I’ll be able to use it for more things, and hopefully get that tight feedback loop back in place.
[+] [-] agumonkey|6 years ago|reply
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.
[+] [-] austincheney|6 years ago|reply
* 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.
[+] [-] jcranmer|6 years ago|reply
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.
[+] [-] seer|6 years ago|reply
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.
[+] [-] AmericanChopper|6 years ago|reply
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.
[+] [-] galaxyLogic|6 years ago|reply
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.
[+] [-] invalidOrTaken|6 years ago|reply
[+] [-] chapliboy|6 years ago|reply
I'm currently trying out vimwiki. Let's see how that goes.
[+] [-] mercer|6 years ago|reply
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.
[+] [-] DJHenk|6 years ago|reply
* 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.
[+] [-] yumaikas|6 years ago|reply
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.
[+] [-] rognjen|6 years ago|reply
[+] [-] MonarchofSouls|6 years ago|reply
[+] [-] GuB-42|6 years ago|reply
"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.
[+] [-] allochthon|6 years ago|reply
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.
[+] [-] eandre|6 years ago|reply
[1] https://encore.dev
[+] [-] srat17|6 years ago|reply
[+] [-] harel|6 years ago|reply
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)
[+] [-] dillonmckay|6 years ago|reply
Good work!
[+] [-] jasoneckert|6 years ago|reply
And starting with #0 adds street cred.