I still find the pressure to work on side projects in your free time difficult to come to terms with. There's often discussion about how if you don't like what you're doing, then you should find a new job - and easily, if you're in the bay area. I know a lot of really talented devs that don't work on side projects because they are completely consumed by, and love, their work and can't imagine doing anything else. What if your passion is your day job?
Having a github full of side projects is helpful when pursuing a job, but I find it difficult to go hard at work and put 100% in and then come home and work on side projects. Usually, I'd rather spend time with friends and family.
This seems to disqualify me from a lot of job postings.
"I find it difficult to go hard at work and put 100% in and then come home and work on side projects."
Then don't.
"Usually, I'd rather spend time with friends and family."
Then do.
"This seems to disqualify me from a lot of job postings."
If getting the job requires a large time commitment to side-projects, then they're not side-projects. If you're only doing something to count towards some job or other, then that is a cost of that job. If you work X hours per week in an office and Y hours a week at home on side-projects you don't want to do, then you're working an (X+Y) hour week. If that's too much, then screw the job because it's clearly not worth it.
With that said, my hobby is programming. I have a few programming side-projects, but they exist for me because I really enjoy them. When I'm not programming I'm usually reading CompSci papers. That's what I get off on. The moment any of this becomes a chore, I leave it to rot. There are a number of dead projects in my wake, but they fulfilled their purpose; I enjoyed creating them and learned from the experience.
Thank you to both the above and above-above for bringing this up. Too often do I see these "you need to do x to be y" or "If you don't do z you're not really passionate", as you said far better than I could have, live the life you want to live. Do what you want to, don't do what you don't; but whichever choice you make, put your all into it, passions and talents will float to the top. While there is something to doing lots of something being how you get good at it, there needs to be more focus on the doing, and less on the getting good at it. This has the side effect of creating what I see as more positive motivations and interactions between fellow do-ers. (citing weak anecdotes from my days as a TA)
I think though is that programming is a tool. You don't need to have side projects to say "oh I have a problem and I think I can quickly hack together a program to address it." And then do it. That's no different really than a chef coming home making himself a sandwich.
Side projects are overrated. Chances are if you have a side project you have a reason for doing it. Maybe there is an open source project that almost meets your needs but is missing that one thing you need.
But I agree that one needs hobbies that are not programming. For example, I study history, play with the kids, do a bunch of other things. I think HeinLein was right, that specialization is for insects and often domain knowledge is as important as programming knowledge. If all you ever do is program, you aren't building the domain knowledge skills you need as well.
I agree with pretty much everything you've said, I think I'd just stress a different point than you responded to; namely that it's more about "not forcing it," "it" being whatever you chose to spend time on, echoing the "no template is right for everyone" sentiment of the grandparent posts.
That being said, I have some hand wavy opinions about the specialization/not specialization question being "at too high a level of abstraction", and that the focus should be on finding some way to impart "drive" (motivation?) into people, regardless of field and focus. I'd like to think on this more but I am currently late for work, so this'll have to do :(
Yeah this is something that's bothered me for a long time. For awhile I felt bad and tried to focus on doing the whole "side projects" thing, but now I've just come to accept that some people will never hire me, and that's OK.
The fact of the matter is that I have a job where I work on different things and am encouraged to learn. It's not a dream job, I don't "love" what I do, but I like it. The fact of the matter when I get home from my 8 (ok, often 7) hour day, I really don't feel like programming anymore. I feel like curling up on the couch with my girlfriend and watching a movie. Or hanging out with friends, or going for a motorcycle ride. You know, those things that keep you from burning out?
So, at this point I've decided that if someone doesn't want to hire me because my Github profile isn't cool enough, well OK. That tells me that the culture there values work over work/life balance, and I don't want to work there anyway.
I work on side projects when I have to urge to, and rarely does anything worthwhile to anyone but me come out of it. But I'm done feeling guilty about it.
I feel like you are setting up a false choice between spending all your free time programming and spending none of it. Taking a few hours here and there to expand your horizons isn't that much to ask.
Here's an idea that might pan out for you! Try to find ways to get your friends and family involved in your projects with you. For example, my fiance is an artist. She doesn't know anything about coding, but we built a social art website working together. She did the designing and visuals, I did the code. It was awesome.
I was able to spend time with her, while also building something that lead to my first real gig as a developer.
One of the best ways to get to know your friends and family at a really close level is by working with them on a project that you both care about.
If a side-project did make any money, what would you spend it on? Perhaps you'd spend some on entertainment, or to further your education, or to finally fix those minor annoyances that you come across day to day. Maybe you'd invest some in a project that you think has great potential to change the world?
Pro tip: many people work on side-projects for exactly those reasons. They just cut out the middle man (money).
Valid point. I guess I'm greedy and could never derive enough enjoyment from a side project, given the energy involved to justify the time investment. I need the million dollar payoff so I can enjoy hacking on whatever I want 40 hours a week.
What? Did I miss some context here? Was this meant as sarcasm or were you serious?
If you don't want to do it fine but calling it insane seems a little overboard. People have hobbies. They do them outside of work. Some one might work on websites at work but have a hobby of making 3d graphics programs at home, or arduino projects, or games, or whatever.
Sure if you don't personally find it fun then don't do it but I guess I read into your message you couldn't see how people could do side projects at home. How are those any different than any other hobbies?
My grandfather was chief of maintenance at some factory meaning he worked with tools all day long fixing machines. He'd then come home and use more tools to make things. It doesn't seem that out of the ordinary.
most of my side projects are for personal use with the goal of reducing the total amount of my life i spend sedentary at a screen. if time is money, then i guess that's something i hope to make money from, but... well, i guess there are just lots of different perspectives on at least a few different topics here.
How do you guys continue learning if not through side projects? Do you only care about the stack you use at work?
The point of doing side projects isn't coding for the sake of coding. It's either to solve a real problem or a means to highlight current technical interests.
Presumably, by figuring out a way to get paid to do whatever you would do in your side projects. For example, build a component of the company's online service in X, to learn X.
I justify work on side-projects when they can both serve my personal goals and the lessons (not necessarily the actual code) can be used to make work easier. So I guess in some ways it feels like doing work at home, but I guess I count it as offsetting stress/tedium at work.
Heres the problem I have with this entire discussion -- and this post does address it a bit -- but programming IS a creative role and needs to be treated as such.
Many organizations hire programmers as technical roles, but they are generally creatives. A lot of them are night owls, who ebb and flow between long productive stints and proverbial 'writers block'.
Many of the best developers I know have a creative desire and just writing code for 10 hours a day doesn't satiate it.
I think we need to start treating developers as creatives and giving them the processes they need to be successful and not be stressed, overworked, stretched thin, etc.
This will never, ever, ever happen. There is too much money, for both sides, in pretending this isn't true.
The business side has been entrusted with a lot of money, its own or someone else's. Success has already been achieved. As such, it approaches things from a mindset of risk reduction. And the absolute worst thing possible, from a risk-reduction standpoint, is creative work. It's unpredictable, you don't know when you've got an end product, and it involves dealing with workers who have egos, who often work on things you don't understand. It is unmanageable, which obviously troubles those whose job it is to manage.
The most common approach, so far, has been to ignore this scary possibility: Keep projects as low-level as possible, spread responsibility far and wide (to reduce risk, not for optimal efficiency), and keep everyone wearing business casual.
Developers are (often) in the weird position of Ozzy Osbourne and other rock stars: potheads whose potheadery became valuable. What the developers know, however, is that businesses don't really want what they have to offer. They don't want to see the full effect of a bad trip. For every Bieber who turns crappy branding to gold in the teen girl demographic, there's Joe Concept Artist who's experimenting with some new grooves, but will never catch on. For every Zuckerberg who can bang out a social network in PHP, there's some dedicated open-source hacker whose dream is to make Lisp accessible to the common man.
And yet: the money guys are offering money. Just swallow your pride, play "Stairway to Heaven"[1] at the wedding, and pretend you've never had crazy eyes when talking about homoiconicity, and the rent will be paid.
As a dev who also sings for a cover band, this post so completely describes my life its scary.
But, I have a bit of a different philosophy.
I think that if you really love something, you'll not only do it for free, but pay to be able to do it.
There are some people who love coding so much that you can't get them to stop. I am not one of those people. I love it enough that I can stand being at my job for 40 hours a week, and I enjoy the time I spend there.
What I really love is Rock & Roll. When I was in high school, I footed the bill for all the tickets my band couldn't sell just for the chance to play on the same stage in Hollywood that a bunch of my idols had played on.
Now I play in a band that plays 90's prog metal covers, something that someone from an 80s/90s pop cover band said no one would ever care about and that we could never get paid for.
He was wrong. People actually love us because instead of just settling for doing what paid, we did what we love, and it just so happens that there was a need for what we love. We're doing our first paid gig in a few weeks.
I love this comment, but it's not the whole story. Mark Zuckerberg made his billions because he built his own company. Musicians do not necessarily need to do this (although it helps them avoid getting screwed), why does Ozzy Osbourne make bank working for other people? Because his value is readily identifiable. You can see his ticket and album sales and TV ratings right in front of you. Everyone can watch his act and evaluate it.
The problem for programmers are that their talent is extremely difficult to evaluate. The best programmers will build a system that avoided so many problems which management will never even have a clue could have happened. Meanwhile, a "rock star" might come in and bang out a prototype that looks so slick and is complete in such a short time that management thinks he is god's gift to programming even if under the hood the code is unintelligible and unmaintainable; when phase two modifications are a disaster, the blame could fall to the new programmer who is objectively much better but is saddled with a terrible technical debt that no one knew about.
It's a classic market for lemons. So management is constantly worried that they have lemons. Giving space for creativity would be much more of a possibility if it was easier to identify the programmers who deserved it.
Well, what you are stating does reflect reality, and that sucks. Pretending otherwise does not make software development predictable, does not make developers' ego disappear, and does not make management capable of understanding what's going on.
But pretend we do. And when everything goes contrary to the expected we make sure that blame is equally distributed so that no party has a right to complain.
Love this reply, it's a summary of cold hard business reality. Seems cynical, but pragmatic and jives with everything I've witnessed. Maybe the parent is coming from a perspective of fostering the next Whatsapp, were 32 people create $16 billion+ in 'value' from within an existing business?
As someone starting a hardware company with amazing software as part of the experience, I am battling the same problem(s).
I want to hire creatives who don't need to be delegated to, and can own full cycle of tasks on their own. I have been doing tons of research in the last two months and a lot of soul searching trying to figure out precisely what makes me tick.
The truth is, every startup WANTS to hire entrepreneurial developers, but rarely let them be entrepreneurs.
In going through this process on my own, for the second time, it is clear that if I want to hire people like me, I have to treat them like I treat myself.
Trust them, give them freedom, and be willing to ask for help when necessary.
I knew someone was going to ask this. I certainly don't have all the answers, but I have thought about this a lot.
First: software is nearly always a dicey proposition. There are so many variables that it's just impossible to predict much about it with any regularity. The best approaches that I've seen so far accept this, and say, "Trial and error? So be it: we will do trial and error as best as it can possibly be done." YC and the lean startup model (aim low, accept that most things will fail) are good examples.
The other approach is the "tried, no error" method, which cares intensely about the past. Hiring a web developer? Portfolio first, examples of use of specific technologies, examples of specific features. Find no one who meets your exact qualifications, and proceed to either a)raise salaries a lot, and constantly (banks, hedge funds), or b) complain to Congress about a "talent shortage" (everyone else).
I think YC is the better model, and is a sort of company-less version of michaelochurch's "open allocation." The key insight is: if you want 10x engineers to ride up on their white horses and save you, you can't presume to tell them what to do. They're cars, not faster horses. Beating a car with a whip won't make it go faster---and this is a feature, not a bug.
To get the best out of developers, you have to accept that they bring risk, and manage around that, rather than blindly trying to reduce it. That's why I think Apple is really fucking smart to have a huge cash cushion like they do: with that cushion., it frees you to go for long shots. Apple is nearly riskless in its financials, and so can afford to be very risky in its product development process.
If I were starting a software company, and knew exactly what I wanted to build, I'd hire people with proven track records, pay them a bazillion dollars each, and give them zero autonomy. Or, I'd hire a bunch of college dropouts who've obssessed over some kernel of good ideas (Tufte, Hickey, FRP, ML), pay them nothing, and let them run wild (this is basically YC's business model).
If you're really serious about this---and I think it's worth it to be---I'd read everything on michaelochurch's blog. He exaggerates, has a chip on his shoulder, uses weird analogies, and has a better understanding of these issues than anyone I can think of.
Thanks for pointing me to the blog. I wish he wrote fewer words while making the same points. I am guilty of the same thing.
Here is where I arrived to so far on this subject from my own reading, thinking and experience:
Each person changes over time - they want varying degrees of responsibility, working on new things, improving existing skills, who they want to work with etc. People age and with that their personal situations change as well.
Change is inevitable.
A company, group of people executing a process which provides value and receives more money than they spend to provide that value, can only survive if it can adapt to change. Both the change coming from individuals in the company and external change coming from the market.
There seem to be almost no companies ( maybe Valve, Semco and few others but I never worked in any of those ) which try to adapt to both the internal changes of their people and external changes of the market.
The current situation is this:
The rigid hierarchical companies with what Michael Church calls "Closed allocation" fail to adapt to both internal and external changes and then they eventually die. What the guy on the ribonfarm blog called - the clueless take over and the losers and sociopaths just jump ship - then the company dies.
In the startup phase, the people make the company change until market fit is achieved.
After market fit is achieved, it causes the company to resist any personal internal change so that the achieved market fit can be optimized. If there is no external change in the market the company thrives and can simply replace any "failed" individuals who no longer fit with external ones which will fit. The company puts in place new individuals to fill the rigid self perpetuating hierarchy which can still provide the same value from the market fit. The company does not care if a great female employee had a child and needs to work 4 hours a day - she is underperforming and needs to be fired for the good of the company. Bigger offices need to be leased and a small group of people who now live far away can just quit and be replaced etc.
Many of the people are not happy but need to pretend they are still the right fit - they just punch in and out - "this is just a job" now.
In case the market fit does not last long but the company has made internal changes impossible - the company will die. If there is still possibility of internal change the company might adapt - but very unlikely if this happens after market fit was once achieved.
Here is my current solution to this.
Recognize that change is inevitable. Embrace it. Create a system which can adapt faster than the change that can cause either personal unhappiness or loss of market fit or profit if you will. The only way to achieve this is to let people inside the company make their own decisions for as much as they are comfortable with.
One way is democracy. People vote and tyranny of majority rules. If you do not show up to vote, whatever is voted gets selected. Every decision is put to a vote or voted to be delegated to people with a finite time limit. The limit passes and a vote needs to happen again. You can even vote for a monarchy in case of crisis - have someone make all the decisions for a period of time. The crucial thing is that any vote has a time limit and another vote is forced - to adapt to change.
Democracy depends on informed participants. No internal company information can be hidden. Salaries are an example of something that needs to be open. Salaries get chosen and budgets get voted for. You select your salary but everyone gets to vote on the budget that salary is in.
Every part of the company should have a time limit - die - and be assembled again. No group should live for more than some time limit without have a vote on who is part of it, what the budget is, what the focus is. Is this done every month, every quarter, every 6 months or a year depends on the situation. But companies need to reinvent themselves.
The time limit on votes forces the answer to "WHY". Is this group needed, did we select the right leader, right people, do we need more, do we need to change the market, product, the janitor ...
Roles and titles cause people to associate with and get put into boxes, and deny latent talents and dismiss insight that could very well be valid. Mgmt consultants make tons of cash repackaging internal feedback into neat, glossy deliverables by basically listening across organizational, preconceptual boundaries.
>but programming IS a creative role and needs to be treated as such.
We need to distinguish between creators and people who just implement, because there is a lot of work that doesn't involve new ideas. Complicating this is the fuzziness between the titles 'engineer' and 'programmer' and 'developer'.
Much of this just seems like growing pains for a field that's relatively new to humanity.
> Many of the best developers I know have a creative desire and just writing code for 10 hours a day doesn't satiate it.
To paraphrase, many of the best X (X being developers, managers, accountants, salesmen etc.) have a creative desire and just doing their job for 10 hours a day doesn't satiate it. That's why they indulge in create activities in their free time.
The majority of programming is analyzing a problem domain and applying the right design pattern. It is not creative. The longer I am at it, well over a decade now, the more this applies.
Software is logic manifest, there is no limit to what can be coded. At any layer of the stack you can radically reenvision the way things are currently done in order to create a new way of doing things, and in no other creative endeavor can you so fully control the minutest detail from the smallest atom to the grandest super-structure. The reason we have design patterns is precisely because the possibilities are so wide open that we need some structure and convention to aid communication and comprehension between programmers.
If you're just churning out cookie cutter patterns you need to get a new job or side project and rediscover the magic.
I'm going to go with the gp on this. I've worked as a programmer for 12+ years (and a few good more as a hobby). I've worked in various industries developing software (games, AI, QA for chemical processes, CRMs for Wine producers, Financial Institutions) and I just don't understand all this talk about programming being so special that we are 'creative' and not everyone can be a programmer talks, and all that new age crap I see exposed here in HN.
When you are learning, yes, probably it is different, but you reach a point when you see programming most things as a chore. There is no magic or unlimited possibilities. There is a goal, and you code to get there. Can we just stop with this bull crap about we being special snowflakes? Just look at your description of software: 'smallest atom to the grandest super-structure' -- Seriously?
What do you define as creativity then? You could say that the majority of writing is composing sentences with nouns and verbs if you look at it from such a low level. (or that artists are just applying specialized techniques to add to or subtract from a medium).
I suppose that you could leave the creativity in engineering to other people (designers, product managers, etc), but my experience has been that you end up a far better product when you engage developers early on in the brainstorming and product planning process and let them help decide what the product should be.
So this is what I was getting at precisely. As buckbova said, programming is problem solving, and solving problems is a creative process.
If you treat developers as creatives (like you do design, etc) you get a superior product and work environment, and you involve more people in the product brain trust.
I disagree that development has come anywhere close to optimizing our design patterns. People are still coming up with better patterns for even basic CRUD and static site generation apps. Coming up with new patterns and improving existing patterns is what we do.
Designing and implementing a software project is not creative. It is learned. It takes methodically analyzing requirements and designing a solution based on learned patterns through study or experience. We engineer software.
"Coming up with new patterns and improving existing patterns is what we do."
Chances are you are not "coming up with new patterns" but instead re-discovering existing patterns.
> Programming, like writing, painting, and music, is chiefly a creative endeavor not a technical one. Practice... will not make you a substantially better programmer. It will just make you more efficient with your tools.
Show me a world-class writer who doesn't obsess about his writing with every waking moment.
Show me a master painter who doesn't paint every single chance she gets.
And show me a music prodigy who hasn't slogged through 15 years of mind-numbing practice every single day.
Only then will I believe that these artists are just getting more "efficient with their tools".
In creative fields, it's even more important that you put in a huge volume of work. That's the only way to connect the dots and create something truly unique.
Consistency my friend. Murakami's routine which involves him running for the first half to the day, then write and then chill with sexy-time Jazz music at time at night and turning in,
I could give you more examples of writers, Joyce Carol Oates , Michael Crichton but same thing basically. Also note that Murakami didn't start writing until 29 and loafed around at the public library chill in' and reading' and at Japanese jazz cafes. As far as I'm concerned, I'm a prodigy and workaholic at 27 for starting so early.
Also in regards to music, others can comment as I'm not an expert. But I've wasted 2 years of my life doodling around scales, ear training and music theory focusing on speed, dexterity and memorization, attempting to learn how to improvise like the greats. That I never taken the time to listen to the groove of the great pieces, sounds wonky but I decided that if I never can become a good musician, at least I could slow down and learn to enjoy the music as opposed to the idea. And I enjoy listening and playing much more now and don't give two-shits about how my solo's sound and just keep playing. And in the small moments of self-delusion inspired by bluesy turns, my own playing gives my deluded mind a self-congratulatory chill to the spine.
And in regards to programming, let's be real. CRUD or iOS apps are not going to change the world. We are like the capitalist work-bees, shoveling digital snow around like escorts shoveling sensual snow. If we are really secure enough to want to dive into our craft, then learn Linux kernel, compilers, advanced algorithms and contribute to the bottom of the stack for a change instead of fluffing snow at the top.
Everything you said was golden, until the last paragraph.
<sarcasm> Picasso really should have stopped faffing about with his silly brushes and gone to work in a canvas factory instead. The world really didn't need another bloody painter. </sarcasm>
However, most guitarists get paid to provide pleasant background music at weddings. Making money writing and playing Purple Haze is a (boom-and-bust, drug-induced) outlier. Master artists aren't employees of Paint-o-Corp who get paid salary in exchange for the rights to their creative output (even if it's side-projects).
If we want a sustainable population of healthy, balanced engineers, we need to adjust our expectations for the typical coder.
Roald Dahl is a great example of a prolific author who would write perhaps 4 hours a day and would spend the rest of his time drinking, relaxing, and tending to his farm. As far as I know, a casual pace like that is pretty common among writers - though maybe not to that extreme.
Slogging through 15 years of practice every day is a technical endeavor. If you need to learn how to do something or to master a technical skill, then yes, volume of work will get you there. Code is a tool that is used to create, and I think the quote you selected just serves to underline the difference between learning how to be an effective engineer vs learning how to become an effective technician.
Edit: constant practice is definitely important, but relentlessly working is not.
I agree that you must put in time to get better, but I think the difference with programming is that more hours does not necessarily result in getting better. Actually, now that I think about it, maybe that's no different than the examples you provided. If you practice violin 14 hours a day, will you really be better than you would if you practiced 8 hours a day and spent the other 6 doing other things?
When programmers get beyond a critical daily/weekly threshold, putting in more hours hurts more than it helps. The brain gets tired of solving problems, and when that happens, pushing yourself further is not the answer. The answer is to do something else, especially something involving physical activity, to allow your brain time to recover.
I believe that many programmers fundamentally do not understand this concept, thus they drive themselves crazy trying to push harder and harder. Yes, you may write more lines of code that way, but at what cost?
I love this[1] interview of Eubie Blake by Marian McPartland for many reasons, but the part where he describes how he at 93-years-old still does daily scales on the piano just goes to show the importance of persistent training in artistic endeavors. I'm a lazy bastard, but I'd only be fooling myself if lack of complete dedication to my craft didn't come at a price.
That said, I have no sympathy for a company that expects to hire a Yo-Yo Ma for the salary of an amateur band member.
I think there is a middle ground between the OP and your comment. I agree with you that the best way to get good at programming is to program. But I also agree with the OP that having other hobbies, interests and letting your mind work on different things will also help you. The ideal balance is some mix of side projects and hobbies.
> Show me a world-class writer who doesn't obsess about his writing with every waking moment.
> Show me a master painter who doesn't paint every single chance she gets.
Well, there's Dante Gabriel Rosetti, who decided one day to give up painting and become a poet. While he is remembered more for his paintings than poetry, his poetry carries with it the essence and soul of his paintings as well as the imagery. He decided to paint with words. I don't think he obsessed about writing all the time. As he put it, though, "A sonnet is a moment's monument."[1]
This gets at what I think is an important point though. All of these creative endeavors require real-world knowledge. Hemmingway went out on adventures. For Tolkein, writing fiction was not his day job (teaching about medieval literature and linguistics, however, was). You can see their respective works that the live of the writer and the other obsessions beyond writing are what make the author.
Similarly with programming, yes, it is a technical endeavor and yes it is a creative one. However just like writing the great works of fiction, these don't come out of nothing. They require a context grounded in other knowledge and experience.
[1] http://web.ics.purdue.edu/~felluga/medievalism/areading.html Note that this was the introductory sonnet to "The House of Life" which chronicals Rosetti falling in love, getting married, coping with his wife's death, and finally finding solace in his religious worldview. The poem, despite its abstract nature is full of classical Greek imagery and something one could probably write volumes about. At the same time, it is an exposition on why he wrote poetry, and it provides the framework for fully understanding the hundred or so sonnets in The House of Life in that way. There are love sonnets, and sonnets which, as he puts it "in Charon's palm it pays the toll to Death" (i.e. allowing the dead and the living to begin to move on).
So your argument is that the primary difference between geniuses and the rest of schlubs is sheer volume of rote practice? I think you're confusing creativity with tool proficiency.
I don't think programming is that much like painting (more than any other craft), but I do think deliberate practice is at the heart of mastering any craft.
More than putting in a huge volume of work, you have to work hard and deliberately at improving every day. That doesn't take (and can't be sustained) for more than a few hours a day, and all other activity is nowhere near as important for development.
As some sort a of music prodigy according to certain people, I'd say you have a point. I've certainly put in a ridiculous amount of time in music "just for fun".
At the same time, to create something great you do have to stop practicing and go back to what you know best and what inspires you.
you omitted a pretty key clause with those ellipses. in its entirety, the quote from the article is clearly targeted at api churn and similar things thrashing everyone's personal caches, not practicing programming in general.
I think problem are working conditions. Modern programmer is expected to work in coffee shop on tiny laptop, practically worst conditions imaginable.
If I ask for decent private office and 3x32" screens I just get blank faces and bullshit excuses. Since I started working for myself remotely, I can sustain 10 hours of uninterrupted concentration. Before in office it was more like 30 minutes of concentration per day.
How much of your productivity gain from the 3x32" screens is attributable to extra space for persistent applications (i.e. always keeping an IDE open on screen N)? Just curious.
I had 4x22" until recently, second screen adds 50% productivity, third 25% and forth about 12.5". Upgrade to 3x32" is underway, so I can not provide data for those. I will probably keep old 22"s around for some statistics, visualisations etc.
I use screens in portrait mode, so it fits more code.
I usually keep left screen for navigation (file managers, terminals), center screen for IDE and right for documentation, notes and communication. I also use virtual desktops to switch window layout for various tasks. For example I consume twitter and rss feeds in separate configuration.
I am not saying everyone would benefit from this setup. I analyze large heap dumps and do lot of concurrent debugging. But quiet office, decent screen and chair should be a starter for any self respecting programmer.
Or worse. In a crowded office that can't control its climate with small screens and poor equipment. The equipment makes a lot of difference, I agree, as does the environment. It's unfortunate that many companies do not realize this and implement policies to cut costs that end up just hurting productivity in general and their bottom lines in the end. To not see this from a management or executive POV is to be intentionally blind. It's a loss all around from the individual to the whole company and one that can't be mitigated against any other way.
I used to find, btw, the pressure of programming difficult to deal with on an ongoing basis. Then one day it occurred to me:
Perfection in the big projects doesn't matter. The world is full of crap software. Perfection in the little pieces however really matters, and this makes it possible to build better software.
I still have stressful days, usually involving bug reports and unhappy users. However, for the most part that realization meant that rather than the stress being an ongoing thing, sometimes lasting days or weeks, it became an occasional thing usually lasting only hours, and the sense of beauty in seeing successful things come together has become more common. That doesn't mean you spend time chasing perfection on every little detail because a lot of things are legitimate tradeoffs and you won't know some deficiencies until it is actually used.
So, when I was growing up, where the family had to drive 50 miles to visit other Asians, I started to realize there was a pattern to how bumf#cks would come circling in for what was in their minds the justified pleasure of humiliating a non-white person. Most people were decent, but I and my family members stuck out.
I notice the same sort of circling at some programmer meet-ups here in the bay area, though I don't think it's my race that prompts it. Programmers make good money, are highly sought after, and in many companies are positively coddled. Just about every group that found itself in such a position has developed some small sub population of arrogant, entitled jerks. In retrospect, I may have been guilty of being a little bit of that myself.
One might like to think that good programmers are also good at thinking rationally in general. That's not how it works. Being good at programming just trains us to think rationally in a very specific context. The rest of the time, we're primates vying for a place in the social hierarchy. The best we can hope for are social structures and patterns that co-opt such tendencies for the uncovering of truth and the good of the group. Seeking social contexts that humanely succeed at this should underly one's seeking for a place of work.
It's hard to do this, and most of the time, people find a situation that achieves group cohesion and effectiveness through an "us vs them" dynamic.
I recently felt the pinch of stress at work...it wasn't due to being overworked though - it was due to being overstressed, due to insane work deadlines that had me concerned about getting stuff done on time. I'm starting to balance that aspect of my life better, with the realization that I shouldn't drive myself crazy just to meet the deadlines given to me. It's ok to let deadlines slip by if they were unreasonable to begin with, but still do the best I reasonably can.
I am feeling like this (burnout/mental sickness of programmers) is becoming a successful theme on HN lately. Many-many posts are popping up to front page.
Not like it's a bad thing, being myself a victim it feels good to read experience of fellow coders who has seen what I am about to see or how to avoid seeing it, but still, it is becoming a theme. I am imagining hordes of posts on this topic coming up. Or may be we already have 'em, just the good ones are popping up to front page.
There are actually more than one pattern emerging. I think I gotta hint of for writing posts more likely to hit front page.
However in the long run it has been and always will be a means to an end.
I think the advice to look afield is good. Gerald Sussman seems to agree as he often looks to biology for new ideas. Ideas are not born in a vacuum after all. They need to form hunches and meet other hunches and be given time to cook. That's a number of metaphors... but I think you get where I'm going with this. I hope.
Spend time learning the fundamentals for sure but branch out as soon as you can.
Impostor syndrome is an artifact of dimensionality. There are hundreds of answers for "What does it mean to be a good programmer?" We have back-end and front-end, "devops" and "DBA" and "data science". We've let the colonizers (business guys) divide us for their purposes (not ours) and we're muddled. It's hard to know if we're good at our jobs because our jobs are constantly changing (and, sometimes, in ways that leave capability and success negatively correlated). The colonizing gendarmes who are supposed to be able to evaluate our work are even more clueless.
What we do would be highly dimensional (i.e. specialized) if we weren't a colonized people. But we'd be able to come to peace with it. We wouldn't fret others knowing more than us (which happens to everyone) if we weren't constantly watching our backs. We are constantly meeting people who know more about certain topics than we do (and, reciprocally, so are they). It wouldn't be an issue if we had more career and income security.
It's not something about programming that makes people sick. It's not an intrinsically stressful activity. It's far less demanding (speaking of the work itself, not context and social dynamics) than over 75% of paid labor. What's hurting us is that we're a lost, conquered, and scatterd tribe. We think we're elite specialists, but we've done such an obnoxiously bad job of fighting for ourselves and our own value as to let ourselves be typecast to business subordinates, and it's horrible.
It would actually be a win for the more progressive business people (as well as us) if we could get ourselves out of this. Would you want to be operated on by a doctor with the pay and social status of an average programmer? Of course not. Well, similarly, we'd make better products if we got ourselves out of the "business subordinate" trap, and pretty much everyone would win.
> Would you want to be operated on by a doctor with the pay and social status of an average programmer?
I don't care about the social status of my medical providers, I care about their competence.
The last few times I've been to a clinic, I've been seen by nurse practitioners instead of MDs. They've been very capable, and noticeably less expensive than an MD visit. Lots of the rules around medical practice are nothing more than the AMA acting as a guild system to artificially restrict supply and inflate salaries.
Having a github full of side projects is helpful when pursuing a job, but I find it difficult to go hard at work and put 100% in and then come home and work on side projects. Usually, I'd rather spend time with friends and family.
This seems to disqualify me from a lot of job postings.