5 ms·
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 great
by austincheney 7y ago
What my years of side projects have taught me:
* At work its better to hurry than get anything done.
Regardless of language if you work for a company of greater than 1000 people there is a certain nearly identical way of doing things. This way of doing things is based upon a combination user platform, quantity of developers on the market with a particular skill, and a need to pretend to be busy even when you don't actually accomplish anything. In most of my experience the platform was the web and the language of choice was Java (even though Java is not a web technology).
When you are working on side projects there are only two goals: don't waste your own time and produce something of value. Nothing else matters. And so you learn to become very productive and extremely focused on what you ship to production, because you would rather be playing games or drinking a beer than pretending to be busy.
The corporate world doesn't work like this. Everybody is paid a salary exchange for 45 hours of your life each week and your assignments are generally governed by an agile sprint cycle, so there is absolutely no motivation to be productive. Maybe if you work twice as hard your bonus will be 5-10% bigger. Maybe if you deliver code that is perfect in that it never requires maintenance and never churns defects you can spend more time reading about foreign places on Wikipedia.
Frustration sets in after watching the corporate approach continuously releasing defective code into production because its important to hurry instead of write things down or write the code correctly the first time. You could always suggest a better way of doing things, but since there is no motivation to do things better all you are really accomplishing is frustrating other people.
* At work don't reinvent the wheel (if somebody/something is capable of doing your job then let them do your job)
When you are working on side projects there is nobody there to do the heavy lifting for you. You can figure it out or it simply isn't important enough to get done. It's the same way with risks and product performance. People who haven't spent time on personal projects or with equity at a start up have no motivation to try harder. That is why there are giant frameworks and a couple 1000 open source packages in your corporate application to solve simple common problems developers are unwilling to solve themselves. Nobody working on a public personal project will build around something like the 1000 ton hammer of the gods that is Angular or Sprint MVC, but you will certainly find these in public facing enterprise applications where developers have no care about punishing their users in exchange for easy.
* You are more productive not doing work
A tremendous part of writing software is the cognitive thinking that occurs away from the keyboard. This could be planning, brainstorming a new feature, reflecting on a past feature, or putting things together in a new way to envision defects or refactoring opportunities. That said, its more valuable to work really hard to accomplish a feature or solve for a defect and then back off from the computer. You haven't stopped thinking about the application, but now you are thinking about the experience or new ways of doing things that you would never think about purely looking at the code. In the corporate world you are extremely lucky to find documentation much less anything like planning or feature engagement from the developers.
- seer 7y agoI’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.
- AmericanChopper 7y ago> 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.