Hacker News Reader

> Just as an example, having to stay in the office if there's nothing else to do for the day was absolutely soul-crushing for me.

> That should literally never be the case for a developer though.

After 20+ years I've both been in such a position FULL TIME, as have others (eg: Many devs at ServiceNow) - hired on to work on cool things at an old small company and then literally sat around every day with no tasks and no responsibilities while everyone around me either didn't show up or watched TV on their monitors (open-plan btw).

I've seen big company devs do the same, making up busy-work tasks and literally not committing any code for months at a time playing the priority-game of "wait until something more important comes up, someone else will make a workaround" which was surprisingly effective.

The reality that a developer shows up and have nothing to do happens OFTEN in all sorts of organizations - eg last day of sprint, how many times have you pulled in a new multi-day ticket? Developer accountability is at an all-time low when software developers (across many sub-disciplines) can't make accurate estimates, can't meet anyone's estimates anyway, and are at an all-time-high demand. Managers are in a different boat, but same result. Perverse incentives and lack of a consensus (or willpower) on what constitutes value makes for do-nothing-and-get-paid while someone else does the work.

In my experience, it is not like that at all. The not having anything to do simply does not happen. What happens is "not being under pressure". But I was always able to find useful stuff to do, not including learning.

I do learning in work time. Learning could be backup for when there is truly nothing to do, like when git is down or something. But those chances are so rare, that I have to learn while there is stuff to do.

> eg last day of sprint, how many times have you pulled in a new multi-day ticket?

I was in exactly one team where you would wait on this situation. In literally all other teams, it was 100% normal to work on something multiday for next sprint. And that one team was dysfunctional in more then one way.

There will always be times when you don't have anything that you've been told to work on.

That is not the same as having nothing to do.

At a certain "senior" level (in terms of attitude rather than job title) you're expected to be a self-starter and think of things to do for yourself. Once you can do that you have no excuse for having nothing to do.

eh, that's not really the case in a lot of developer jobs these days. A lot of agile/scrum adoption/bastardization has meant that all work done has to be decided by the team and pretty much every piece of work has to be approved by a product manager. This can often lead to some demoralising meetings where you can either lie about the effort/risk/goal or you can give a true value estimate that gets shot down. If you lie, you can end up spending your own free time working on that refactor or documentation etc. For most devs working on a codebase, its not theirs, and they don't determine what has priority.

In reality, for a lot of people, if you start refactoring the codebase while waiting for a new task you are likely to break something and its just not worth the hassle for the developer or the company.

Learning new tools is always great ofc but it can be very hard to find the motivation in such a role, where unless you are a senior developer, you probably won't have much say on adoption, and you will likley just develop a half baked understanding of a new library that you will never get to use in production. Its much better to have some real free time where you can focus on your own projects and learn that way.

So in short, maybe it should never be the case that devs are in that position, but it often is. Especially for devs with less experience

> if you start refactoring the codebase while waiting for a new task you are likely to break something

The risk of this is in proportion to the lack of test coverage. If you are afraid to refactor, this should be an indication that you need to apply more test coverage, so do that first.

That’s pretty sad and disempowering. For what it’s worth at companies like Facebook it’s completely the opposite. If you aren’t taking any initiative you will not meet expectations at performance review.

I just had a good chuckle at this. I’m skeptical, to say the least. I don’t have direct experience. But I do work at a company that has poached several FAANG employees this past year and whose thoughts...differ from yours.

I can second dkasper's observations -- the PSC cycle is engineered to reward initiative. That said, depending on the team, the practice does not always follow the theory, so it makes sense that the FB employees your company could poach may have been the ones unsatisfied with the way their team rewarded initiative.

Kent Beck became a former Facebook employee because he wasn't in to proving he was moving the needle on Facebook's key metrics. He was only giving world class mentoring to young Facebook engineers and improving the development culture.

Likely you were able to poach them since they didn't thrive in that environment. Or you got them from the more traditional top-down Microsoft, Apple or Amazon.

Or he paid more, had more interesting work, clear path leadership was present, wfh options, family vibe, stock options, less corporate culture, etc..

That sounds like academia, where people are also expected to be constantly innovative on demand and, when the majority just can't pull it off, they invent BS research and produce worthless papers which clog the system.

> If you see those things as "the boring bits" that you don't want to do then you're not a developer. You're a hacker.

Well put. Professional software is only a mean for business not an end by itself. I recommend not deriving your satisfaction from code only if you work for a company otherwise you risk to both spoil your hobby and always be unhappy at work.

So what do you derive satisfaction from if you don't enjoy coding for its own sake?

Problem solving

I agree with your overall sentiment, but:

> If you see those things as "the boring bits" that you don't want to do then you're not a developer.

Don't we already have enough gatekeeping in software development? I don't particularly enjoy writing documentation, despite how important I know it to be. That doesn't make me "not a developer." If I were lazy and simply chose not to do the things that bored me (despite their importance), it might make me a bad developer (or more accurately a developer of bad software).

I design and implement software. That makes me a software developer. The pieces of that process that I find boring or exciting are tangentially related at best.

People are better at what they enjoy, but I know very few people who enjoy documentation. I have apent most of my career as what the gp would call a hacker. My redeeming quality is probably my love of testing. I despise formal methodologies and processes, and people who fall in love with tools or languages or language features are hard for me to work with.

I don’t understand that general lack of love for writing documentation. It’s a part I like very much in a project: explaining how it works, why some things are done a certain way, the limitations of the software, the possible configuration options... It’s funto write.

I definitely don't begrudge anyone who likes documentation - but we all have different parts of the dev cycle that we like - some folks love to architect solutions and hate implementation because of the fiddly bits and details - other people dislike the stress of having to come up with overarching approaches and get analysis paralysis but when it comes to splatting out the vision into code it's meditative. Still other folks love to break things and enjoy needling edge cases in unit tests (if you find one of these or are one of these - know their value, they are a hot commodity). Then other folks love the teaching/explaining part that comes with documentation.

I think that there is a way we can improve as an industry to let more people specialize into their niches (which would move us closer to a factory/assembly line sort of setup) but right now most developers are artisans that receive some vague ticket and produce code and everything for it as a result.

I appreciate the validation, as much as I like to see things eork, I also love to break things. Pathological unit tests are fun, but the real low hanging fruit is in finding how two services implemented the same service contract with different assumptions.

> Don't we already have enough gatekeeping in software development?

No. In fact I hope anyone who's actually worked in the software industry would see that we don't have nearly enough!

Look I'll agree with you about the evils of gatekeeping if we're talking about who gets to call themselves an artist or a writer. Those kinds of distinctions rarely create life or death consequences.

But software can. Not all the time, but certainly in medical, airplane control, banking and financial, and many many more areas.

I wish software would take notes from other engineering fields like structural or architectural. Can you imagine an engineer building a bridge who was like "I don't want to do the boring stuff like stress analysis or geological surveys, I just want to make cool shapes and build them!" Can you imagine trusting your life to a bridge built like that?

Software increasingly runs our world and real software engineers who work on things that really actually matter know they have a responsibility to "do all the boring things" because those things are essential to doing their job right. Hearing about major hacks and exploits every day like SolarWinds, Experian, Facebook that expose our personal information and put us at risk makes me feel like we desperately need more gatekeeping in our field to keep cowboys and hackers from getting the chance to get anywhere near these systems.

I've been in this career for 20 years and the thing I learn more and more is that writing code is perhaps the most trivial aspect of what we do. It's everything around it -- the process, the testing, the security, the collaboration and how teams and organizations operate that are the real challenges to be solved. Anyone can hack together some working code. The hard part is the systems and organizational structures in which it operates.

There are plenty of things to work on in software which are of no real consequence, but as the OP is finding it's pretty difficult to find someone who wants to pay you to work on something which has no value. That's called a hobby not a profession.

Huh. Plus one to you -- you have meaningfully changed my opinion.

As important as those things feel after 20 years you must remember you are hired to write code. As easy as code is to write without none of the other processes are required.

If they wanted someone to just write documentation you wouldn't be hired. A technical writer would be.

If they wanted someone to just test you wouldn't be hired. A QA person would.

Same for whatever processes you create. They would hire a process specialist.

Same for project management. They would hire a pmp certified person first.

Same for business analysis and business requirement gathering.

As a developer there are better people to do all of those jobs at better rates. None of them can code. That's why you are hired. If you couldn't do that than your qa abilities don't matter.

Things have changed over 20 years. Not every company has a qa team or bas or support team. So these tasks end up being picked up by the developer. Often if this slows development teams are created of non-developer specialists. Some developers end up doing very little coding because your job is to go to meetings about projects that never start. But you are still hired to code they just need you on standby.

Anyone cannot hack together something that works. Only a developer can. A hacker would find ways to use an existing system in an unintended ways.

Gatekeeping over this makes you more management than developer.

The tao of programming has a different understanding of what a developer is and isn't

https://www.mit.edu/~xela/tao.html

If the organization or the product has any amount of complexity, all of those have communication roadblocks. While it’s technically possible to always be learning or practicing something, much of the effort will be wasted by either a focused or a bureaucratic organization. Repeatedly doing work just to give the company an unlikely option on it is counter-productive as it leads to burnout. It’s better to stop work when enough is done for the day or week to stay focused on the efforts that matter.

Probably the best way to apply the “if you have time to lean, you have time to clean” mindset, if it must assert itself, is to actually let developers stuff packages or weed the grounds or something else that can clear their minds. :)

> If you see those things as "the boring bits" that you don't want to do then you're not a developer. You're a hacker.

This point parallels the distinction made in the Software Engineering at Google flamingo book between programming and engineering. Engineering comprises the tools and processes to maintain software over time (this is a rough paraphrase), of which docs, for example, is essential.

So to use their language with your point: this sounds purely like programming and perhaps not engineering.