Live data from Hacker News

What eight years of side projects have taught me (2019)

junglecoder.com

41–50 of 91 posts

Re: What eight years of side projects have taught me (2019)

#41

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 alway…

If that is the case, wouldn't it be better to hone design and product skills instead of coding?

Re: What eight years of side projects have taught me (2019)

#42

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,.. :)

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.

Re: What eight years of side projects have taught me (2019)

#43

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 ac…

> 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…

> 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?

Re: What eight years of side projects have taught me (2019)

#44

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 alway…

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.

Re: What eight years of side projects have taught me (2019)

#45
post #8

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.

Re: What eight years of side projects have taught me (2019)

#46
post #17

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

Offtopic: what kind of UI library/framework/whatever did you use for that landing page? (For example: bootstrap?)

Re: What eight years of side projects have taught me (2019)

#47
post #45
post #8

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.

Close - Haskell & purescript!

Re: What eight years of side projects have taught me (2019)

#48
> 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.

Re: What eight years of side projects have taught me (2019)

#49

Earlier quoted context omitted.

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…

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.

Re: What eight years of side projects have taught me (2019)

#50

Earlier quoted context omitted.

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…

> 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 h…

> 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.

Post reply on HN