* 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.
> 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?
> developing your career or your skills/competencies?
GP was saying that you only develop your career by developing skills. React is a skill, so is Angular, so is the wide world of front-end web programming.
I disagree those are tools, like an grossly enormous hammer. If you had learned data structures, the DOM, storage, and all the other things that comprise the platform your opinions of the available tools would change. Nobody else in the world immediately jumps to nuclear weapons as their first stage tool. Only in software do we immediately jump to the nuclear option for all tasks, and there is something wrong with that.
You're describing the opposite extreme. Most people are aware that they need to strike a balance: be aware of your own marketability versus just doing enough but not burning themselves up.
Being more or less productive is defined by - in no particular order - your salary, workplace culture (a due sense of agency and feeling respected,...), your own intrinsic motivation to choose a particular career path and personal circumstances that keep one at a job (usually household debt in any way shape or form).
Contrast that with the fact that digital tech today is an industry in which a large part of your toolbox and knowledge is perceived as "obsolete" within a short time (1 or 2 years). The net result is that most people burn themselves out in a race they can't hope to ever finish.
So the notion that "you must keep up at all costs" is unsustainable to put it mildly.
> They’ll probably get small raises every year, and perhaps the occasional promotion based on years served. But that’s really as good as it gets for them.
And that's totally valid. Why do people need to forcefully "climb the ladder" through promotions? A promotion isn't just a reward, it's often a serious career change that comes with serious challenges.
If someone wants to move vertically in a particular role throughout their career - say, as a developer - then that's totally fine too.
If someone isn't interested in spending time at home working on OSS projects - even when their employer provides incentives - then that's fine as well.
> They’re usually very friendly to work with, but they’ll have skills that are 10-20 years out of date, and mediocre at that. Eventually even the slow moving large organisations start to outpace their own personal development, and they get left looking for jobs that don’t really exist anymore.
That's a bias. Not every large organisation operates like a silicon valley style start up. Not every organisation has "building cutting-edge software" as a primary mission.
Banks, airlines, public institutions,... don't operate on short timescales (5 or 10 years), they operate on long timescales (20 to 50 years out). They aren't interested in shiny tech, they are interested in robust & proven solutions that last a very long time.
A large chunk of software engineering is boring and slow moving for a good reason: because breaking things comes with serious real world consequences.
Case in point: there's still demand for COBOL and Perl programmers. You can perfectly build a career in as an expert in those areas.
> I worked with a guy a few years ago, and all he’d ever really done was Swing projects. He added me on LinkedIn a few months ago, he’s been working at a cinema for the past two years, trying to find a new Swing project to work on.
Anecdotal.
If he works at a cinema, that might be because he can't simply move to another area with more swing projects (family or other concerns), or because he genuinely got tired and wanted something else, or because he just doesn't know how to promote himself properly - it's not his strong suit - and he turned to LinkedIn just recently.
Unless this is a close friend, you do not know half of this person's life and their decisions. Assuming x because y, well, that's just jumping to conclusions, isn't it then?
No, I’m simply debunking the parent commenter’s assertion that “there is absolutely no motivation to be productive”.
> a large part of your toolbox and knowledge is perceived as "obsolete" within a short time (1 or 2 years)
This is a major exaggeration. I do a fair number of node projects. I did my first one ~8 years ago. I don’t think I’m close to doing my last one, and it hasn’t been hard to keep up with the changes in that time.
> Banks, airlines, public institutions,... don't operate on short timescales (5 or 10 years), they operate on long timescales (20 to 50 years out). They aren't interested in shiny tech
I feel like you haven’t worked in a bank or airline before. Most of them have ancient tech in their core infrastructure, but a) they’re not happy about that, they just don’t know how to change it and b) a vast majority of their technical workforce will have no contact with that at all. Your average sized bank will typically employ 0 DB2 DBAs (they’ll all just be contracted from IBM), and a very small team of Cobol devs. You could work writing code in a bank for 10 years and never meet one. Banks and airlines are constantly trying to modernize (especially since they’ve realized how much money they can save by employing SREs/DevOps engineers). They love shiny new tech. A large portion of my consulting work comes from such organisations that are highly motivated to implement it.
> there's still demand for COBOL and Perl programmers. You can perfectly build a career in as an expert in those areas.
No you can’t. Today’s COBOL engineers are the ones that survived getting laid off when banks decided they didn’t want to invest in COBOL anymore. There’s essentially no entry level COBOL jobs on the market today.
> you do not know half of this person's life and their decisions
I know he got laid off, and that he’s been looking for work since then. I also know his skill set is no longer in particularly high demand. I see this happen all the time. A significant portion of my work comes from large organisations seeking to modernize their technical capabilities. They tend to be filled with people like him when I start, and a non-trivial portion of them tend to be gone a year later (all of the ones who couldn’t adapt to the new technology).
> might be because he can't simply move to another area with more swing projects
There is really no such place. There are still companies that use technology like that, but the number of them is shrinking every year, and people aren’t using it for new projects.
The bottom line is that even in large inefficient organisations, there is still a strong incentive to be productive and to invest in developing your own skills. Most people expect their careers to last 45+ years. Even if it takes 10 years for your skills to become obsolete in a slow moving organisation, you’d still have to spend the first 35 of those years developing your skills.
> it hasn’t been hard to keep up with the changes in that time.
That depends entirely on your context. Debt, disability, dependents, other personal goals,...
Not everyone can easily spend nights and weekends following what goes on in the JavaScript, Go and IoT space at the same time.
> a) they’re not happy about that, they just don’t know how to change it
It's called "opportunity cost" and "risk management". They rather stick with what works - the best of all the worse alternatives - instead of stepping into the unknown. Personal happiness on the part of the staff is subservient to that strategy.
Don't confuse the opinions of the tech staff with the mindset upstairs.
> b) a vast majority of their technical workforce will have no contact with that at all.
Goes without saying.
> Cobol devs
I choose COBOL and Perl as random examples of niches. There is tons of legacy infrastructure to be maintained beyond COBOL and Perl as well.
> They love shiny new tech. A large portion of my consulting work comes from such organisations that are highly motivated to implement it.
Of course they do. But shiny tech only gets to be implemented in place where failure is factored against the potential gains.
Put differently, a mobile app being unresponsive for 15 minutes is an annoyance. Banking or medical records getting corrupted or lost, is a disaster that simply can't ever happen.
> A significant portion of my work comes from large organisations seeking to modernize their technical capabilities. They tend to be filled with people like him when I start, and a non-trivial portion of them tend to be gone a year later (all of the ones who couldn’t adapt to the new technology).
That's bad management based on short-term thinking, and it has absolutely nothing to do with technical skills.
Modernization isn't about the tech, it's about reducing costs. Employees are seen as a liability. Always. And so lay-offs and modernization go hand in hand. The hidden cost is the loss of institutional knowledge and culture.
Instead, they try to cheap out by bringing in consultants, like you, to do work on a per-project basis. But that doesn't create any institutional knowledge. Instead, it makes them utterly dependent on the volatility of the consultancy market.
Down the line, what you get are stories like the trainwreck which is Boeing.
Even if those employees did spend time learning Node in their free time, they would still have lost their jobs. Simply because their salaries, and the protections & benefits that salaried employers enjoy, made them unattractive.
And those who did learn, well, they left long before the writing was on the wall anyway, because the only reason reason to invest time and effort in your own skills is for your own sake, not the sake of your employer.
Finally, working for yourself, or working as an outplaced resource comes with many drawbacks. It may work out fine if you are healthy and you're in a situation that allows you to do that type of work. But those conditions can change at any time.
Private corporations and enterprises aren't charity. It's sensible to reduce costs as you go in order to stay competitive. But when corporations do that in such a way that the labour markets get stiffled, income levels stagnate or decrease and the fabric of society gets pressured, well, that's just predatory capitalism.
If you can live in such an environment, then that's great for you. But judging others because they struggle? That's a hard nope right there.
> 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.
* 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.