Do you hate software engineering but love programming?

> I have come to a realization that I don't really enjoy Software Engineering(& the processes that it comes with) but I do love programming & solving problems.

I can almost guarantee that you’re just at the wrong company.

Some software companies can turn even the simplest tasks into a grueling series of processes, endless meetings, and joint work across a big number of “stakeholders”. These companies will take the joy and productivity out of programming and replace it with a series of rituals and set of language that people use to go through the motions every week so they can collect paychecks.

Start interviewing around. Talk to your network. Find a company that values programming and real productivity but discourages unnecessary meetings and process. You will be much happier. There is no escaping the fact that you’ll have to work on legacy code, document your work, and meet with people some times. However, it doesn’t have to be a miserable process-filled slog.

I am the exact opposite. I mean, I don’t like processes and meetings, but I do like the planning and architecture part much more than I like actually writing code.

Usually, if your mind is decently organized, I find that the problem is solved before writing a single line of code. If that happens, then the actual part of writing becomes dull and mechanical - the problem has already been solved.

I’ve never understood people that just jump into coding without much of a plan - and I think the industry has shifted towards that a lot these past years. Everyone is used to learning by doing, and pretty much everyone seems to have an aversion towards reading and documenting. I feel I’m slowly becoming part of a minority.

I love most of the things around writing code but absolutely despise all the people that have popped up around it. Software engineering feels like a jobs program where we let nontechnical freeloaders figure out how to insert themselves into our process. I think that part of the reason that software sucks so much now is that the people designing it don't love software and technology the way we do, and it shows. I think we need to get nontechnical people OUT of our process and encourage more to be obsessive technical "lifers" and not corporate randos with business degrees trying to tell us how to make stuff.

Every few months or so we get these really circle jerky posts by engineers who believe the world of business is them just pumping out code and somehow getting paid.

1) that’s the difference between a job and a hobby. You do the hard parts you’re paid to do sometimes.

2) decisions you don’t like by stakeholders you don’t like aren’t always wrong just because you see some way to “code it”. A product is not just its code base. It’s is also the design, marketing, revenue and growth strategies. Sometimes even more than the code base. Sometimes code can solve these issues but more often it can’t.

3) this view often attracts comments from engineers who seem to have very limited experience in building and running successful products that can pay the bills. It requires a lot of hard work you don’t love. Yes you can find others to do that work but that’s you. You’re the one hired to do the work higher ups don’t.

If you disagree you can start your own business and learn for yourself. A business is a lot more that solving interesting problems and calling it a day. It’s building, growing and managing a business and the tasks that go along with it.

The strangest thing is that I love refactoring, and I sort of assume that it's another one of those things that programmers love to do, but managers keep pushing us to limit our time and move on to things that are visible to customers. But now I'm wondering if that's not the case. Or maybe it's just the sort of programmer who loves abstractions and is cast as a "perfectionist".

I'm currently getting my footing now as a contractor. If this is actually something that most programmers don't like to do, is there an angle for me to pitch myself as "The guy who will clean up your code base"?

I dislike now that everything seems to be hacking around frameworks and dependencies, people don't want to (or can't) write code anymore. This is of course a rant, but you get the point. The following in a contrived example, just mentally replace it with whatever horror you've seen.

There's an awful lot of very nice good quality libraries, frameworks and 3rd party code that I'm very grateful for. But there's also a lot of hacky stuff around that people blindly import as dependencies. Then it becomes someones else headache (mine!) to deal with it.

I get a task to add a feature which isn't supported by the library that the new dev imported into the system. Turns out this library was someone's introduction to the C language and they decided to publish it.

It pipes unhygienic user input straight to system calls and has boundary issues. It's mostly one function with a lot of conditional checks on arguments. There are three copies of the source file, one for each supported platform.

I'm left with a insane task, PTSD and a deadline on Friday.

Do I just pretend I didn't see that and hack in another feature? No.

Do I tell the boss the problem? Yes. Will it delay the release? No, there's a demo on Monday and we have to release on Friday. Why Friday, we shouldn't release on Fridays!

Sounds like most of us you like developing but dont like working in other people's code and design.

Corporate work has a bad reputation but lots of upsides. I work in a small team of 5 people on a system that has about 40 users. Its amazingly better when you can talk to everyone, know what all the users want, dont have to worry about constant uptime or scalability. Flexibility and budget to pay for good platforms. Just dont talk about the refactoring - rewrite from scratch!

Reply: Yes it is expensive, the users are all paid more than us though which means we're helping them be productive. I have to add we also own a second application that has about 100 users that we spend some time on maintenance and support.

> I'd rather get to value now by making something that just works(and is adequately tested) than engineer something thats future proof but takes longer to get out.

If you haven't read it, I highly recommend A Philosophy of Software Design by John Ousterhout. His talk is a great teaser for the book: https://www.youtube.com/watch?v=bmSAYlu0NcY

Here's the thing: a program properly written for the future does not take longer to get out. Not much, at least. What we instinctively think of as "future proof" is generally anything but: by anticipating some particular kind of change that may happen some time in the future, but in practice almost never does, we end up with more complex programs that are harder to modify when an actual (typically unforeseen) change comes our way.

The best way to future proof your program is to make it simpler, according to the requirement you are currently aware of. If you expect a particular change, sure, plan for it. But for the unexpected, just keep it simple. Because simple is easier to adapt, add to, or rewrite.

That said, the simplest solution is rarely the most obvious. Making thing simple does take a bit more time than rushing through the first thing that comes to mind. But it also pays off in a matter of weeks, so it's quite worth it.

And if you have a hard time assessing what "simple" means, SLoC is a surprisingly good metric (we have research that shows this). And mostly your modules should be deep: small APIs that hide significant implementations. I think of it as encapsulation on steroids.

It’s going to sound a bit harsh, but what you hate is engineering discipline. Every engineer I know absolutely hates it but it’s like being an adult. There’s a ton of things that suck but it’s important to do in order to survive. Most process suck and some are even bloated. But they’re there usually for a reason (mostly good). No good product is sustainable without engineers with good discipline.

I tend to like engineering, but that's because I'm sort of a completionist. I like finishing stuff. I like getting to the point where I no longer have to worry about it, and I do a good job, the first time, so I no longer have to worry about it.

I like to F^3: Finite, Focused, and Finished:

    - Finite: I know what "done" looks like. Tasks have a discrete beginning and end, though the schedule may be fuzzy.

    - Focused: No distractions. I stay on beam, and devote full attention to the task at hand.

    - Finished: I don't stop, until I have reached a point that I can wrap things. I usually punctuate this with a final tagged commit.

I've come to realize that this is kind of an aberration.

I cover it, in a way, in this post: https://littlegreenviper.com/miscellany/thats-not-what-ships...

Things were better before agile / scrum / annoying processes took over.

Not all companies were waterfall, they kind of just "did things" without any well defined process. This was how things were until roughly the early 2010's. I remember working for weeks, after a couple of whiteboard sessions. You'd meet about what you were going to do, work on it, and come back a week or two later. Occasionally there would be informal check ins.

I (Mostly) agree with you here:

> Finding and fixing bugs is a lot of fun. Incidence response is a lot of fun. Hacking on new projects is a lot of fun. Writing unit tests is fun too.

I'd agree on the first three, I'm not a huge fan of unit tests though. They seem like something a "good programmer" should do but to me it's in in the CYA lane, not programming.

> Refactoring, rewriting, sprint, agile, rearchitecting things etc aren't that fun.

I actually like refactoring code. To me it's like pruning a garden, moving stuff around to fit better. It also helps me on longer running projects to fix up crap that I wrote months/years ago. I'm always growing as a developer, and fixing foundations so they don't end up a cobbled mess is actually a pride point for me.

Agile / Sprints / Pre-Future proofing / API contract writing? Pure overhead for me. My current job is a ridiculous amount of meetings. I get like 15-20 hours of meetings weekly in my position.

This really boils down to being at a company that doesn't have technically knowledgeable management, and being on projects without a dedicated architect.

I strongly dislike enterprise development/engineering, but I love programming/engineering. Enterprise software is written to optimize for the most amount of people working on any given codebase. As a result the practices and conventions adopted tend to sacrifice many programming techniques that would otherwise prevent a number of recurring problems.

This is also why pure functional programming never takes off despite being the more advanced and sophisticated way that leverages techniques which would prevent bugs and speed up development. I understand why large companies prefer extremely verbose, repetitive code, which allows for easy scaling of engineers, but I wonder what the industry could be if engineers prioritized computer science - more robust codebases, faster development which would translate to better products that never break while at the same time evolve faster.

"Planned obsolescence" might make business sense for hardware, but I feel software has so much wasted potential at the moment.

I come from an era when not liking your job was the way things were. You could enjoy the social camaraderie, lunch and your paycheck. The army did an excellent job of preparing me for that situation.

With all that said I do love programming the way it used to be. You could often be allowed to write something pretty. (From a pure code perspective)

At the uni. I had that freedom as well.

These days solutions usually surround using duct tape, plastic straws, and a half-broken welder to force various components and 3rd party APIs to work together, even though they are usually never designed to work in that way.

Then a vendor changes its API, we need to connect to yet another service, and some people who see resume padding as their biggest goal in life will manage to throw the latest hyped products / frameworks / tool into the mix.

It is a monumental task to write that code to be pretty.

A lot of software engineers care a lot more that we are using the latest hotness than they do about making it pretty.

Not an answer to your question, but some perspective from my own experience.

I worked with a bunch of people like yourself at a fast-paced adtech startup. Clean code and even sustainability were not a priority, and the company had a money printer in the basement. Has the front-end gotten so messy it's unmaintainable? No problem, let's make a new one from scratch! I loved that we were given so much time to solve interesting problems with bleeding-edge tech, but I hated the filth of the code, particularly trying to read other hackers' code. And yes, so extreme was the priority of haste that these engineers were more hackers than anything else. That wasn't really my style, so I left.

Now I work with people who are the opposite. They love fussing about the `describe` blocks in their unit tests, will draw up Excel sheets to supplement the JIRA board, and spend an afternoon arguing about whether that 100% test coverage is really covering all functionality. The codebase is a textbook of how to write beautifully maintainable, readable code. Pull requests are genuinely enjoyable. But ask them to learn a technology from the last 8 years and they just start refining their refactoring tickets.

Perhaps I will find a happy medium between these two extremes.

The truth is that "programming & solving problems" is only ever a fraction of a programmer's job even at the coolest company. You'll always end up having to first figure out other people's code and data, coordinate teamwork, support production environments, refine expectations (a.k.a. finding out what "the real problem" is), document critical procedures, improve tooling, and so much other _stuff_. And it's totally ok, because these things can be fun too! And because when you finally get to write code, if you're just a bit smart, you'll consider these other aspects and give them appropriate care in the way you code, so that maybe things are easier for everyone in the long run.

What steals the fun out of the profession is the process, whether it's agile or lean or whatever. Having someone breathing down your neck for every bit of work you do, trying to categorize and measure every activity into a rigid grid to try and demonstrate a form of control over a process that we all know is essentially organic, if not chaotic. Smaller workplaces generally have much less decorum but given enough time all will grow their own process.

At some point you figure out that the ultimate "problem" is always of human nature. The code you are paid to write and the problems you are paid to solve are _not_ yours. And that's precisely why you're getting paid.

Maybe most of the contemporary practice of 'software engineering' is playing house.

For example, "refactoring" used to mean a kind of later code changes to a working system, and tools to support it. Now I more often hear of it being used to mean what I'll call "fudge-factoring", to try to finish or redo a mess the same person made (possibly the previous week) so that they could pretend a sprint task was done, for metrics/peer-pressure reasons.

Genuine software engineering is hard, but there are crafts to it, and you can find satisfaction and even aesthetic appeal in the crafts. And it can let you accomplish things that you either couldn't accomplish otherwise, or couldn't accomplish as easily.

Maybe a comparison with programming is helpful. Programming is hard, but there's satisfying craft to it when you're doing it well, and when things come together.

Now imagine the programming is being done badly -- most of your time is spent debugging, structural changes to the immediate code base are difficult, the tools are lousy, you have to spend other time figuring out some low-quality bureaucracy bloat other people made, people who don't know what they're doing have created a lot of wrong-headed theatre around pretending to address these programming-level problems, etc.

That programming done badly is a lot like software engineering being done badly.

Could a mythical software engineering done well be what you want? What if it wasn't piles of bureaucracy, but some magic professionalism that extended what you could accomplish with programming, removing some limits you found on what you could build before?

As a self-taught software developer, I understand your feelings. Many tutorials, workshops, and boot camps focus on the technical aspects of software development. Coding, fixing bugs, and handling incidents are thrilling and give a sense of accomplishment.

However, when the applications I built became older, as more and more people started using them, and as the underlying tech stack continued to release new versions every year, I found myself spending more and more time patching up code to fix issues reported by users. I was patching the same code again and again or doing the exact change at ten different places and messing up in multiple ways. Since these applications were mission-critical for my clients, there was no way to avoid this.

I realized that behind-the-scenes, "boring" concepts of planning, refactoring, discussing with team members, and architecting were essential for my future as a developer. These practices allow me to spend more time on the "fun" aspects of development and less on the "boring" stuff.

It's similar to going to the gym. It may not seem important in the short term, but it's essential for a healthy long-term future.

Sounds like you should join an early stage startup - like 5-15 people in the whole company. There will be lots of rapid development of new features, lots of outages, and minimal process. There will still be some refactoring/rearchitecting, but with a lot less code and a lot less users you can do it a lot faster.

You could also consider agency work. There will be more process, a lot more checking in with stakeholders, but you’ll build a wide variety of greenfield projects, and sounds like that’s important to you.

Refactoring is super fun, that's the part where I learn the most:

after writing many features, adding the next one gets harder and complicated in my head, that's when I know that the code needs to be much cleaner so that adding the next feature becomes easy.

It often means that I delete code / completely skip a code base that went in the wrong direction and overcomplicated some part unnecesarily. And that's when my code gets much more elegant by achieving more and being simpler at the same time. I love it.

Does anybody enjoy the boring, non-programming bits of software engineering?

I look at it like professional sports. There's a saying: you're paid to practice, 'cause the actual games are fun.

That's the way I look at it. I'd write code for free, more or less. My employer is paying me for all the other crap I slog through: gnarly legacy code, weird bugs, endless meetings, etc.

Software engineering vs programming? Sounds to me like work vs hobby dilemma. I love programming but I hate doing documentation, non-conclusive/watered-down meetings, seeking consensus with 10+ people and scrum master "friendly advice". Nevertheless I am doing that because I _got paid_.

As other people suggested you may consider switching to a green field project. Usually when there is a new product to write, you don't have a legacy code baggage and business is usually pushing for fast delivery and iteration. There is a lot of freedom, as long as you can deliver a working solution. Startup would be a good choice about 3 years ago, today I would advise to be more careful when changing jobs now.

I co-founded a company as the only software developer and it's the most fun I've ever had building software. That includes all the refactoring, architecting and rewriting. What's important in my case is that I have awesome co-founders who have completely different roles and skills and that trust me to deliver the tech. We don't have investors, only our own money on the line. We also don't have any recurring meetings, communication is mostly async and that works great for developing software. There is a vision and a rough roadmap but we don't do any short term planning, that would be a giant waste of time. We just had a very successful first year!

The job is not without any hard parts though. I may have a lot of freedom to build a product the way I want, but I didn't have any technical colleagues to discuss problems (or joke around) with. A start-up naturally comes with a lot of uncertainty. You have to make a lot of hard decisions and then make sure they were the right ones. And it might take some time before I make as much money as I did working for someone else.

Every job will have pros and cons and you'll always need to make some trade offs.

Yeah. I love writing code, but working with others while doing it has usually been unpleasant. The recurring theme is that management doesn’t understand how software is written, ignores tech debt, sets unrealistic and arbitrary deadlines, etc.

I have worked places where it was pleasant working with others though, and those have been small companies. There always seems to be a lot of bullshit once a company reaches a certain size.

That's me... I loved coding, I did it in my spare time. Then I got a job it's been downhill since then. I thought maybe I was a junior. Then I thought I was at the wrong company. Then I told him maybe I was working in the role or programming stack?.

But that's not it, I like writing code, I like refactoring code, I like debugging code but I don't like that it'd be held as a knife to my throat every day forever.

At my job there has never been a slow day. At one of my past job our manager had to go for 2 weeks and that was the most productive we had ever been. We shipped more , built more , collaborated more, and it all felt like a breeze.

Right now I feel as engineers we have been subjugated to being a coding monkey. You are told what to do, when to do, how to do and how much you should have done by now. You are monitored, of made to dance, and forced to be glad that you even have the chance.

I've spoken to people who have been in the industry for 10 15 years and they say this was not how it used to be

If you don't refactor, as you program new features the code will rot. The best time to refactor is when you add a new feature the codebase didn't anticipate - this is how we do it at my job. Do you not consider this refactoring? Or do you just bolt on things as you go?

Or do you consider refactoring something like "OK, we have 2 weeks to refactor the codebase" - because IMHO that's not a great way to do it. Instead, at work we follow the scout rule: make the code a little better each time you touch it. This is still refactoring.

And we don't do sprints either. We just have a priority list and however long the next thing takes is however long it takes. We do rough estimates but don't hold people's feet to the fire. Rarely we have deadlines and things DO need to be done by a certain time for that, but that is due to external marketing/etc. This usually only happens a couple times per year.

It's best to learn to deal with processes. Some companies do have really bad ones, and if that happens you should leave, but all companies will have some level of process, and every job will have some amount of work you don't like doing.

Learning how to deal with this is a career skill. Remember that to your employer, you are not a coder, just as a firefighter is not a hose operator.

To your employer, you are someone who delivers, maintains, and supports software. That requires a lot of non-coding work, and as you advance in your career the time demand for the non-coding parts of the job will increase.

If you know how to deal with processes -- how to streamline them, avoid them, delegate them, and use them to your advantage -- you can build the kind of role you want. So, the good job for a person like you is a job where you understand how to work the processes in your organization.

Something to be mindful of (but I'm not saying it's necessarily true here) is that it can sometimes be easy to re-frame the statement, "I like the fun parts but hate the work parts" into something like what you've said. Eg. "Does anyone else love playing hockey but hate practices?"

I love solving problems and fixing bugs. I LOVE optimization (when appropriate). But these are like 10% of what I'm paid for and I appreciate it can't all be the fun stuff.

An attitude recalibration may be helpful in this case. Software engineering is merely your "profession", and you perform it in exchange for other people providing you with clean water, cheap goods, security, etc. (Whether that's a fair trade is a different discussion).

Unless you're an owner or a shareholder you're essentially a skilled laborer. Clock in, ply your trade, clock out. If they're jerking you around on hours get a better job or "quiet quit". Do things you like and feel fulfilled about in your free time, it's better to take joy and meaning in the society that you theoretically are working for the privilege of living in rather than looking for that satisfaction in your work.

A quote I often think about from an article titled Smart Guy Productivity--"Son, I don't go to a place called fun, I go to a place called work."

> Refactoring, rewriting, sprint, agile, rearchitecting things etc aren't that fun.

Well you might not be aware but refactoring and rewriting are essential to any good codebase. No software is perfect because we aren't, and if you don't constantly keep fixing things (refactoring is fixing bad design), you will end up with a bunch of garbage to collect (pun!). Regarding methodologies and frameworks like agile and scrum (which includes sprints), you need some way to organize shit in an organization, real world problems cost the companies a lot of money, which in turn needs to be controlled as best as possible, agile & scrum are one of the ways we handle such things. I myself am not a fan of "trying to control the world" but it's necessary, I gotta suck it up and keep myself in harmony with others.

> I'd rather get to value now by making something that just works(and is adequately tested) than engineer something thats future proof but takes longer to get out.

This right here is why people argue over tests. So you believe you don't like rigorous testing, which is your opinion and it could/couldn't be valid based on the situation. If you are developing a program that controls airplanes, you need to make that as flawless as possible, otherwise you'll endanger lives. But yeah, if you're building a website for a small sweatshop, you can ignore tests and risk the occasional bad user experience that might happen due to your bugs.

All this being said, to answer "What are some good jobs for a person like this?", I can assure you, you can find lots of jobs you will like if you understand why these things exist. I have worked on a project that management preferred to avoid tests and keep things flowing quickly, so your "getting shit done" mentality might be satisfied easily. Try figuring out exactly what you dislike and WHY you dislike them, only then you can figure out what kind of company (maybe smaller-sized ones) will best match your liking.

Ha, I'd say rearchitecting is fun and incident response is not fun.

I think there are parts of the process that people enjoy over others and that's based on many factors, personality, company culture, managers, coworkers, process and tooling, etc.

You don't have to enjoy every aspect of it. Just like enjoying cooking, and not enjoying doing the dishes.

The important part is being professional, doing what's asked, not being negative about it, and look for opportunities to improve that part of it.

You don't like jobs not software engineering.

Rarely is software engineering as currently practiced actually "engineering" and "problem solving". We are mostly creating even more problems due to unreliable methodology forced down our throat. Hell, we can't even reliably identify bugs given extensive testing, fuzzing, and code review. Fashion trends like microservices cannot contain the impact of bugs in one service; all hell break loose. Instead, microservice practice aligns the software layout with HR layout (a la Conway) even more faithfully than monoliths did, and this outcome is the antithesis of engineering.

This is what Albert Camus described as "absurd". I suggest reading "The Myth of Sisyphus". That book will shed some light on how one should live in this funny world.

A lot of startups fit this bill, or otherwise small companies. But you do need to dig into the company to be sure, I have seen very heavy “agile” processes dripping with bureaucracy get installed in surprisingly small startups (with predictably bad results).

Ask around places (like here!) what their SDLC is like, and if they ask you what an SDLC is you may hit onto an ideal company )or the worst possible one :-) ).

Probably don’t bother with consulting or services firms. Look for industries that can benefit from software but maybe doesn’t have big “enterprise” players yet. Consider areas like embedded and IoT where you can pretend it’s the 80s and you are shoe horning features onto tiny CPU’s with little RAM.

Alternatively, code as a hobby on the side, if you have the time and will power for it.

Find a job where you can work alone on something, maybe. Working alone removes much hassle. You also list 'refactoring' as something that you don't like. This will be part of any programming job as soon as it outgrows 'hello world' by only a small amount. Furthermore, you list 'agile' as something you don't like. Originally 'agile' was intended as being able to respond quickly to changing wishes from the users, not as all of the (in)famous 'agile' ceremonies. If you also want to remove the former from the equation, you limit yourself even further and I think it would be hard to get a job that satisfies all of those demands.

I feel like I am maybe "lazy" sometime because I avoid doing work because I know how painful it's going to be to get from working to "done". It just often doesn't seem worth the effort.

When I work outside the constraints of my day job, programming is a fun creative pastime that makes the hours fly by. Last night I was up until 4am just hacking on something I was interested in. I honestly didn't notice the time go by (probably not healthy, but hey I was having a lot of fun so it's fine for me)

The engineers I really respect often say similar things. There seems to be a gatekeeping class of software engineer who've been overfed on design patterns and enterprise software dogma that suck the fun out of it in big teams.

I'm relatively young in my career, <5 years experience. I did a year at a company that forced me into meetings and planning for huge chunks of the day, nearly every day. It really made me develop a hatred for agile and all the process bullshit.

Recently this year I switched to a job that gives me hard problems to solve and turns me loose on them. I still need to attend standup and planning meetings but management is very hands off and respects my time. My productivity and love for my job has multiplied incredibly.

I think management can be a force multiplier or a complete anchor depending on their attitude. Some people need to be managed to be kept on task but for a lot of us who have a love for programming a hands off approach is much better in my opinion.

Being too reliant on Atlassian products ruins the fun. Blindly following patterns aren't necessarily fun either.

Personally I think I enjoy solving problems with just enough tech. I roll my eyes when I see hyped tech/practices tossed in with everything. I know somebody that works in a hospital as a unit clerk, and they supposedly use JIRA and are Agile.

In short, there's a lot of fake work.

Back in the day agile was meant to let you program more. Then the process people came in and made it a tedious monstrosity. Then the management came in and made it unbearably oppressive.

We need a reboot and a flight back to utility. But it was so hard to pull off in the 90’s, I’m worried we never will recapture software development from the people who hate to program.

One thing I've realized is that a lot of people I know don't actually like programming or software engineering in general. A lot of my coworkers just do it because it's the tool they need to do their job (like using a hammer). It's tough because I love programming and geeking out about it, but it feels like no one around me feels the same way

Do you hate software engineering but love programming?

Nope. I love the engineering aspects that go beyond "Just programming". I don't always agree with some of the details of how those processes work, but it's all fundamentally important stuff and I enjoy working on it. I do like to keep processes as lightweight as possible though.

Slightly off topic but my pet peeve is most people who call themselves "Software Engineers" are not engineers. They have not studied any engineering at all

There was a fashion for a while to call people "Software Architects". I do not know what happened to it but I fantasise that some architect society got busy and put a stop to it.

I am a computer programmer. I do things that "software engineers" do, but I do not lie about my qualifications, which are all in science and commerce.

Computer programming is a noble craft, we do not have to put on airs.

I feel you. I am good at making software, I love doing it, but I dislike all the cooperate bullshit around it.

What really gave me back the love to programming, building and even some corporate bullshit was doing my own things. Just solve a small problem, get really good at it and if you get bored just start working on the next thing.

You choose your own tools, your working hours and how big you want to get. My suggestion is to stay small and safe time for new projects :)

You take seems to be "I like some parts of programming/SE but not other parts".

I like:

- Designing and architecting software

- Writing new code (e.g. new project or feature)

- Refactoring and rewriting existing code

- Automation: finding new ways to do things faster and eliminate mechanical processes (not just new tools, but knowledge, e.g. learning algorithms so that when I see a need for one I just up an existing library or snippet instead of re-discovering it myself)

- Using Linux and command line tools (related to automation, but also setting up big servers and processes is cool)

I don't like:

- Debugging

- Writing "hacky" code (prefer to write code which should last long and be maintainably)

- Testing

- Sprint/agile and other long processes

- Certain languages (e.g. JavaScript) and

I really don't like:

- Working on projects where the code quality is bad

- Anything mechanical which can't be automated for some reason

Anyways the point is that different people like working on different things, a decent number of people like doing most of the things which you hate and vice versa. So you sgould try to the right job and position where you can work more on the stuff you like, and less on the stuff you don't like. It's not software engineering which is the problem, it's certain parts of software engineering, and while you like can't entirely avoid all of those parts, in the right company I'm sure you can focus less on them and more of the parts you do like. Or, you can always try to get some easy job for the sake of getting paid, and do side projects and open-source work

I haven’t spent much time thinking about the full extent of the metaphor I’m about to propose. But what you’re saying sounds to me something like “do you hate being in a relationship but love making love?” Yes, many people would prefer one without the other. But that’s not how it works in real life most of the time.

And not only engineering vs programming or relationships vs love making. If you pay attention, many other aspects of life are like this too: — do you like learning but hate school? — do you like hiking but hate waking up early, driving, and sweating? — do you like seeing new places but hate planning and getting there?

Granted, sometimes some people manage to arrange their circumstances such that there’s no dichotomy there. But most of the time, on average, this is what it is. There are two ways of dealing with it: accept it as a fact and learn to deal with it or try to change your circumstances with the understanding that there’s a high chance it’s going to be the same at another place.

A lot of this comes down to managers.

I have been blessed to have really great managers who have been able to insulate the team from all the BS, while allowing us to unleash our creativity and talent in making great and useful software.

Basically, they deal with all the pain so we don't have to, and as a result their teams have really delivered great value for the company.

My solution: I am a book publisher (age 50, 25 years in publishing). But during my life I found that I deeply love programming too in a way you mentioned – solving problems. Small, private conundrums. Sometimes creating simple apps. But just as a hobby!

If I had to make money by coding, this all would be gone.

So: do another job and code for fun. :)

SE should be one of those "if it's not fun, you're doing it wrong" things no?

alternatively, consider that it's just a minor component of programming in general: it doesn't deserve to be called a field: just like "using sandpaper" is just one of many activities within the profession of carpentry.

we do SE in order to program.

"I like a few languages and I am not too keen on learning new paradigms or languages unless I have to"

You're in the wrong job.

A developer has to keep on top of tech industry or they'll become a dinosaur early and find trouble getting work after you lose your job (just ask Java devs who steadfastly refuse to move off anything but Java 8).

Firefighting issues ("incidence response") due to lack of software engineering is not enjoyable when you've just manually deployed to production from your desktop computer and put the wrong build on that has migrated a prod db schema used by millions of people to one that isn't compatible with the rollback version of the software. And you'll be fixing it across your holiday and weekends.

There's a reason these processes are in place - and its to stop the wild west cowboyisms bringing down the company.

No not at all. Software Engineering is about building systems to the appropriate quality level.

For projects I'm usually involved in: this means being disciplined, writing good quality tests, keeping code clean, documentation and following the various practises and conventions. This, if you're doing it properly, means you'll be able to ship code much faster than if just "programming".

I use scrum by choice; but you can deploy a lightweight version that cuts a lot of the bullshit if you have a good team.

If you're re-architecting things then that's a huge red flag. Unless the underlying assumptions have changed enormously or you're working for a start-up who had inept "programmers" (like myself 20 years ago) YOLO'd V1 then what you're doing ain't engineering.

13 years ago I was so passionate about programing and software engineering. I used to stay in front of screen consucutively for 48 hours. But, now I realize that it was not for me. I tried to commit sucide three times. I was not good at soft skills. Though I solved many complex technical problems at work but did not excel in career. Its been 4 months I am jobless and I dont want to code again. I think software engineering and coding is the most painful job on the earth. I prefer death over doing it again. On the other hand I am running out of cash, I have two kids not sure what will happen in next 3 months.

People will disagree with me here, and at the end of the day I might just be getting hung up on semantics. But I don't think that the processes that come with sprints and agile are what change it from being "just programming" into "software engineering".

I took this off of the Wikipedia article for "Engineering", but pretty much every definition I've seen says something like this:

> Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tunnels, roads, vehicles, and buildings

So if you're using scientific principles, i.e. you apply knowledge from sub-fields of computer science such as distributed systems or cryptography, then you're doing software engineering. Sometimes this is important, e.g. you need to understand how a system will scale under load if it is used by a large number of users. Other times it's not so important.

But all that agile process stuff? That's not science, nor software engineering - it's just project management. Sometimes project management is important, such as when you need to coordinate large groups of people, or manage delivery risks. But in my (probably overly) cynical opinion, Agile (in practice, big A, etc) is usually just a heavy-handed way for companies to micro-manage under-performing teams - and at least for me, this is the biggest thing that just completely sucks the joy out of programming.

> What are some good jobs for a person like this?

So given the above, I'd suggest seeking out companies that are working on interesting problems that require computer science principles to be applied, rather than just another enterprise CRUD app where the hardest part is dealing with the business stakeholders.

And avoid companies that require a lot of project management - places where every bit of work requires coordinating a larger number of people than you would normally think necessary. This is most big companies, but also a lot of small companies too.

Unfortunately, this takes a lot of jobs off the table. But if you're able to find something that fits you, that's a great result.

Sounds like you hate having a job. You'll just have to do what most people on the planet do – suck it up and bear with it. It would be great if we could solve fun programming puzzles all day, but there are bills to pay.

Like you I was sick of software engineering but still really enjoy programming. I was fortunate enough to be able to retire early and I now enjoy programming a few hours a day on various personal projects and open source.

Maybe try an operations teams at a <200-300 employee company? Been on a few platform operations teams/systems operations teams where most people are working in yaml or one-off cli tools. Those teams are usually a mix of people who can code and can't. If you can code you get a lot of freedom to work on whatever you want without sprints/strict design docs/required tests. Just need to make sure a potential team has enough people that not everyone is fire fighting all the time. Pay is good at the right company.

I feel the same way. In my experience doing software development consulting, this is the difference between a startup (5-25 people) versus a larger org (75+ people). The bigger orgs are all too happy to saddle you with endless meetings and agile busywork to the point that you're only actually coding about 5 hours a week.

Startups on the other hand don't have time for all the bullshit because they're going to run out of money if they don't actually deliver. It's more stressful, more chaotic, but also more fun.

Funny! I might be the opposite

I like doing all the things that avoids the weird debugging and incident response. Maybe I'm old. I like lowering my mental load understanding a code base. Unit tests are annoying work, but I love the headaches they save. In the end, I love the feeling of being able to feel 'safe' changing and deploying code, and feel like it's going to be rock solid in production.

Programming, on the other hand, is kind of a chore. And I'm happy to see CoPilot, etc...

I hate IT. I hate dealing with many developers in a professional setting. They're too busy trying to look good and move up a ladder. A lot also don't even really want to do actual work. If there are two solutions and one is clearly superior but a bit harder to do most people want to wimp out and do the easy solution and deal with a bunch of pain for 6 months that could have been avoided if they spent an extra 2 weeks doing the original development work.

Software engineering != feature factories, bodyshops, most big tech and mid tech projects, etc. There are not so many people consistently doing software engineering.

Yes, I have never seen a working agile process. Only development where developers can either sleep the majority of the day or need to finish some death march for a feature management suddenly decided was needed yesterday to keep the company alive. Everything everyone is doing is theater, smoke and mirrors and clownery, kept alive by some implementation-champions and the super rare competent business people that burn themselves out.

Software Engineering is disgusting.

The purpose of commercial employment is to do something useful for others, not personal enjoyment and self fulfillment. Obviously, enjoyment and self fulfillment can be coincidentally found at work, and there is nothing wrong with considering that as a factor in addition to compensation. But if you really want to 100% enjoy hacking, set time aside for a hobby. Retro programming like MS-DOS is one example where you will never be tempted to compromise fun for other considerations, since there is no practical or even charity market for end results. Plus, inherent platform limitations severely restrict bigger picture software engineering.

Put it another way, say you found a hacking-only job. Would you enjoy commute, having to show up on time when tired, layoff worries, reprimands from manager, inevitable coworkers with personality issues? The only way is to code without commitments to others.

Ironically, once you got your hacking fix in, you might reach a point where you run into limitations of coding without plan and structure and start appreciating early design reviews to avoid wasted work / code reviews to avoid get bogged down by a week of debugging that could have been an hour of hardening.

Yes! Web stacks have grown too convoluted and round-about. I used to do what's now called "full stack development" for small and medium applications. But that's almost impossible to do well and efficiently because web stacks shot YAGNI and KISS bloody dead. It now often takes layer specialist to do it well. Some say we have to burn what desktop IDE's did well to get HTTP-based apps, but I haven't seen any solid proof they are mutually exclusive. It just needs more R&D.

We need new web UI standards that are CRUD-friendly. Social media and e-commerce have been wagging the web UI dog, but CRUD matters: it's not sexy, but runs the world. Standards improvements or addition possibilities include a state-ful GUI markup language (sort of like the best of YAML, XUL, & QML), and/or do something like Java Applets correctly, learning from security and version/package-management mistakes of the past.

Similar opinion: https://www.reddit.com/r/webdev/comments/r59nzr/i_regret_goi...

I hear ya. Agile really made working in software unpleasant. I long for the time the team had a simple spreadsheet of items to work on. So much more efficient.

I'm a little different... I love programming and am "okay" with software engineering. But my first several years coding were in Lisp, so I developed an idiosyncratic style, and have to "tone down the lispiness" when coding with other people. I enjoy working w/ other people, but would love it if there were more people who's brains were twisted the same way mine is.

> Finding and fixing bugs is a lot of fun. Incidence response is a lot of fun. > What are some good jobs for a person like this?

SRE/Devops person at a FAANG.

What exactly is your definition and/or interpretation of software engineering? And how exactly, in your eyes, is it different from programming?

I'm very similar to you!

I'm a research software engineer at a medical research institution in Sydney. I'm the only engineer / developer type person on my team, and I work with other microbiologists, physicians and bioinformaticians (who know scripting/programming but specifically for answering biological questions). The system I'm building tracks samples in the lab, patient data coming in from the hospitals, and genomics data from the sequencing lab and bioinformaticians.

I do "engineer" type things, but I have full autonomy and I support the rest of the team. What we do is impactful too — our clinical trial just treated three patients.

I don't write unit tests because I can't be bothered. I do write documentation though, but for myself.

Downsides are: it gets lonely being the only one that does this, and there's no one to bounce ideas off of; no one else knows what you work on or understands what you're building (which can be a good or a bad thing); you're that "IT person" in the back.

Oh and the pay is awful compared to real tech jobs

Research & Development, Academia. Gigs where you're paid to experiment and try things out at your pace. If you can find something super niche it can be similar. Helps to be an expert in your field / very smart.

If you just want to 'get something out now', join a startup. They're full of amateurs churning out terrible code at a rapid pace with no thought to the future

It's a little unclear what you actually "hate" here. To me, refactoring, rewriting, and rearchitecting are very different things than sprints, agile, and all that process.

If you hate the process, then it's probably easiest to find another job with process you can tolerate - especially if the current process is working for your company. If enough people are frustrated by it you may have some luck getting the company to introduce a new process, but I'd expect an uphill battle.

If it's really software engineering and architecture that bothers you, though, I'd strongly suggest giving it another try. "Making something that just works" now, is awesome when you're writing the code in the first place, but it's an absolute maintenance nightmare, and it won't be long before you're drowning in tech debt.

A whole team where everybody says "lets just do the first thing that works" may work for a treehouse or a shed, but you'll never build a skyscraper or big project that way.

The process that comes with it is there to organize the work and align it with the organization's goals. It can be agile, kanban, waterfall with big upfront design, it doesn't really matter what methodology is used, its there to organize the work. For large and/or existing systems, without that glue there would be programmers running amok solving problems they like to solve with whatever shiny things they want to use. I'm sure without guardrails there are a lot of engineers that would re-write all the code they didn't like, building their own bike sheds all over the place.

Sounds like maybe startups would be your jam. Not a lot of legacy stuff to work on, lots of bouncing around to different types of tasks, shit breaks a lot, etc.

The other idea is more of devops/systems stuff working with the cloud. Lots of solving problems with code (orchestrating cloud resources w/code) with not a lot of Project Manager overhead in the right environment. Lot of incident response.

I hate entrepise softwares, matrix organizations, SaaS products, sales teams and sales architects but I enjoy developing, making products, helping business users, so these days, I am wondering why I even stay in this fields. Switzerland is a rather small market, and I don't feel that going back to France would be great. So just stuck in my daily routine...

You'd be better off freelancing with that mindset, or working at a smaller startup where your role is more "full stack".

If you're competent enough, you should be heading towards a founding engineer kind of job. "Refactoring, rewriting, sprint, agile, rearchitecting things etc aren't that fun" - exactly this, but at the same time, it generates insane amounts of experience, so your situation sounds like you learned everything you want about the bad processes and you're ready to implement your own good processes.

The things we don't enjoy most of the time carry stress and fear factors within, fear can be eliminated with knowledge, stress can be toned down with simplicity, if you already know all this you can turn any process into joy if you are having such responsibilities, or you can make your own from scratch

Analyst

Researcher

Artist

Analyst meaning a person who works with something like Jupyter Notebooks or VBA in Excel to do non-recurring work. Researcher meaning an academic or corporate researcher who tries experiments in code to prove our concepts. Artist meaning a person making fun things like art, cosplay, entertainment, games that can’t hurt people and don’t need high reliability.

> Refactoring, rewriting, sprint, agile, rearchitecting things etc aren't that fun.

Speak for yourself. Lots of those things are fun. Sprint and agile have more to do with the workplace, sure. But refactoring, rewriting and rearchitecting things can be really fun. The first implementation of anything is going to be burdened by complexity and wrong assumptions. It's only on the second time through that you have clarity. The joy of having the solution work pales in comparison to knowing that the underlying code is a thing of beauty. Like a jacket with a beautiful lining, paying attention to the details that nobody sees makes your product inherently better.

> Finding and fixing bugs is a lot of fun.

Refactoring is a part of this process. Squashing bugs and edge cases is fun like playing whack-a-mole, but it's also fun to see the bugs and edge cases as a chance to question your assumptions, is this really a one-off, or could I prevent all bugs of this kind in some way?

Do you actually just like programming and hate “engineering” side of things?

What if you just did programming but we’re told how to program?

Sometimes people get burned by processes and sometimes people just don’t want others opinion and want to do their own way in their own world.

I honestly go through ebbs and flows between the two and honestly I think a good middle ground is some process. I’ve learned a lot (and literally did just yesterday from an RFD review) so I can’t dismiss process altogether.

If I want more autonomy I’d work at a smaller company. I do miss the days of my old company where I wrote so much of the system. From payments to auth to order and fulfillment. It was fun, and I knew everyone in the company. Thinking more about it writing this just now though, I think my code would’ve been better with more reviewers nudging in the design process.

You might want to consider doing some open source hobby work as well btw; I am doing that rn.

To quote the book by Google software engineers, “Software engineering is programming integrated over time”.

Programming is writing code at one snapshot in time.

Software engineering is mapping that code backwards and forwards through time, making sure it works with what comes before and what comes after, in both technical and business aspects.

Hate the industry but love the craft, is the advice I can give you.

Programing is first and foremost a craft which just so happens to employ a lot of people and tends to pay pretty well. There is nothing wrong with keeping programing as a hobby and finding a different career. I personally know a couple of talented programmers that work in other industries.

This kind of mentality is way common in some other industries. Woodworking and apparel jump quick to mind. I bet the number of talented woodworkers that don’t have a woodworking career is pretty high.

If you don’t want to change careers, then there are some companies that value the craft more then others. In my experience the smaller the startup the more they value the craft (which unfortunately is negatively correlated with pay). Perhaps you can love your job more if you worked at a different company.

I feel similarly. What I've found is that the way companies are structured the software engineers are usually in some sort of software department. I try to aim for roles outside of that department, like a software engineer embedded in some group that's more directly tied to the application.

I've found that if I'm in the software department, the performance review and metrics and overall culture lean towards "how good of a software developer/engineer are you?" as opposed to "how good are you at solving the business's problem."

That said, it's tough to make progress outside of the software org. Personally I'm doing a masters in math right now and thinking about a PhD in it as well, because I need skills outside of software in order to be able to make programming part of my job but not my career.

I wouldn't place all the blame on sprints, fauxagile, etc.

The industry is driven by fashion and medium.com-led development.

If you're not jumping on the in-vogue band-wagon then you'll be punished.

After a while you've seen it again and again and you want to avoid it. But that puts you at odds with the industry and employers.

Tangent, but I realized the same thing about competitive gaming. Games can be a lot of fun when you’re playing with noobs and you’re a noob yourself. But when you get good and start playing with good people then there’s all these things that you need to do all the time and that you need to be aware of. It demands a lot of focus, and rigor, and poop shoveling type of redundant tasks (e.g. always zigzaging when you walk to avoid snipers) that a lot of the fun is lost. But of course, competing at a high level is something that’s also much more rewarding, and in that sense shipping a serious product that’s used by many people is much more rewarding to fucking around. Doesn’t mean you can’t do both. Maybe that’s why I have so much fun when I discover a new language or framework.

The place I work at recently grew and have adopted this agile scrum thing. We had a course that prepared us for it, but if I'm being honest, I just don't get it. I mean breaking a feature down into smaller pieces, sure I guess that helps. MVP, sure I understand although however you explain it to the client, they always freak out when they use it for the first time. I guess this means they only said they understood when they didn't really. But then there are the meetings and they waffle on about numbers and improving performance. I mean, what am I supposed to do about that? Give me a task and I will try to understand it and do it in a timely manner. That's all I can give you. What exactly is it that you want?

Engineering (and Software Engineering) is all about building a bridge that barely stands. Tuning the entire process to be cheap as possible with as little risk as can be stomached. It’s very concerned with what happened in the past, to feed into those decisions.

Science (and Computer Science) is all about getting a giant telescope into space. Tuning the entire process to discover and keep working when it finds some new and unexpected. It’s very concerned with what might happen in the future, and uses those predictions to feed into current decisions.

It sounds to me like you’ve got it backwards. It’s the science you don’t much enjoy. Maybe try your hand at something like project management to get closer to the engineering role?

May I suggest you to take another look at refactoring? I think that if you love unit testing and debugging, you probably would love refactoring too. I like that I don't have to worry to find the perfect name for my functions and methods _on the first try_, and that I can focus in making code that works first, and after that I can worry in making clearer and more understandable.

Now, to be fair, I also like the common practices in the industry too. Scrum or kanban, ticket creation and estimation, and daily stand ups. When you're part of a team you need a lot of communication and effort to keep everybody working in the same direction. Besides, managers want to be kept informed. The how is not as important as the why.

Simple hints for your type

  * Find smaller company
  * If possible find company that does some real business and needs software to run it. These are the best from my experience. I am not an employee but this is how I find my clients.
  * If you hear words agile, process, methodology start from the beginning
  * On the interview you should be asked what have you accomplished and how, how you could help to solve their problem.
  * If instead they would start grilling you on what that tiny dot in this particular language means, ask you to complete particular tests, write code during interview start from the beginning

Obviously you should have some portfolio, some verifiable references and know what you are doing.

Not just you. Software development, especially web, is a very pretentious industry. I believe that itll be one of the first programming jobs that'll fall to AI if it happens someday (no, systen architecture is not some special, difficult skill only some of us can have as they'd have you believe). Embedded, OS, scientific programming, they do real work there.

Take a magazine like POC||GTFO and see what real engineering looks like. Recently I came across a nice challenge there to write a program for which the compiled binary must be a palindrome. Good stuff. If you can afford, switch to something like embedded development. You'll probably make less in the short term but you'll get to keep your soul.

But I think that's what truly makes it "engineering." Programming and solving problems are fun in a vacuum but tech is just a lot more than that. Being able to produce a solution to a problem today doesn't mean that the same solution will work tomorrow. That's why we have to _engineer_ a solution, not just produce one.

I'd argue this is true of any engineering discipline. For example consider this analogy: we build bridges to solve the problem of being unable to cross to the other side. But we could also solve this with, say, a boat, to paddle ourselves across the body of water instead; in fact, that's a much more immediate solution that solves the exact same problem. But is it sustainable? Is it scalable? Can it handle traffic? To address these concerns, we _engineer_ a bridge.

Software that's meant to service a lot of people can't just be written to solve a particular problem today -- it must be _engineered_ so that it's future-proof, which is to say, easy to scale, easy to read, easy to refactor, etc. So often the simplest programming challenges become particularly difficult and often interesting engineering challenges.

Finally, to actually answer your question, it entirely depends on the company, the size of the team, and the commitment to code quality and engineering that that team has. Working at Google on the search team, for example, wouldn't be a great fit for you because every line of code you write has to be engineered! But working at a startup might.

But this comes with tradeoffs. Often times, the solution you write will have to be rewritten if you want your product to succeed. Refactoring and re-architecting things are a necessary evil as technology, hardware, and languages + frameworks change over time. I've worked at places where I've found myself repeatedly having to work on the same things over and over again because of how poorly engineered they are! If you enjoy programming and solving new problems and you want to have a career doing that where presumably you're building some sort of product, you have to engineer at least somewhat reasonable solutions today so that you can work on something new, exciting, and cool tomorrow.

“I'd rather get to value now by making something that just works(… and is tested)”

IMO that is the gold standard for 80% of professional software. Ship. Fix bugs if needed. Ship.

If your org wants to do pointless cargo cult process junk and this troubles you, switch employers. Preferably to a place with old steady hands.

Software engineering is not the problem. Problem are orgs that invent pointless process and encourage the managerial types to get some more process in. Not all shops are like that (yet… at least).

I suppose you can probe this at the interview. Too little process and too much are both res flags. Too little:no CI, no testing, that sort of stuff. Too much: like porn, you know when you see it.

It's not that I hate it. I just don't care much about the problems that people actually pay programmers to solve. I'd rather think about the interesting stuff for which there doesn't seem to be much of a market.

I have never found a job that maximises the fun parts of being a software developer. To my mind, anything but programming is what you're being paid to do - nobody wants to do that and it sucks. The programming itself is the art, the fun. You hope it makes up for your colleagues and possibly the incredibly unethical company you work for.

After I've written this I realise it sounds super depressing. I would honestly not mind if there was an answer to this :)

When I read the title I was curious what definition of “engineering” would be in play. I wouldn’t call the process around programming and problem solving “engineering”. I’d just call that “process”, or “overhead”, or (when feeling like speaking plainly, “inefficiency”). Who loves that? It’s necessary, but loving it certainly isn’t necessary (or even good?).

I’d call the problem solving that balances technical, human, economic factors and produces great code “engineering”. Knocking out code on a whim less so.

My message is just be careful who you’re speaking to when saying you don’t want to engineer — I’m my book you do.

I agree completely and have felt this way for years. And this is despite me getting a job at a "good job" (good benefits, generally respectful etc, cool language and tech).

I went fully remote way before COVID. I've figured out how to cut my work with sawdust to get paid at work, and nowadays I'd say I spend more hours per workday on personal projects (programming and otherwise) than company work.

So basically, I recommend making your job a low priority and focus on finding a remote company who will be happy with your output at that level of focus. Then you can get paid to do what you want in a way.

I think you just need a different workplace. A much smaller company? Academic/non-profit/scientific? The latter might mean a lot less money (that's where I work), but you might love it more.

Rearchitecing and higher level system design are some of my favorite things. I really like thinking about big software systems. I also enjoy programming and implementation quite a lot.

The one thing that's getting more and more prominent that really hounds me is DevOps, tooling and deployment related stuff. Be it containerization, credentials, complicated toolchains and dev environment setup, I absolutely hate how convoluted all of this has become and how little anything of it has to do with the actual software you're supposed to build.

I actually prefer software engineering to pure coding.

Pure coding honestly is boring after many years. There's a limited amount of times I can write code that listens to some event, manipulates data and passes it eventually to some api.

Doesn't matter if it's augmented reality, databases, cli tools, it's always the same thing.

On the other hand I find much more interesting setting up projects, their DX, their architecture, solving clients/customers problems under limited time and budget constrains.

Sounds like you could enjoy being a security engineer and focus of identifying and addressing security vulnerabilities in sofware/systems. More problem solving, less engineering. Or maybe just go for a pet project with people you actually like, because the aversion to processes might just be a sign of bad management.

I actually enjoy the parts you don't seem to - architecture, refactoring, designeding systems from teh ground up is what I really enjoy. Debugging - my own code, fair enough, that's my responsibility, when it's other people badly written code, not so much. Sprint and agile is meh, but I guess you need a way of organizing a team. uess I like focusing on the large scale parts of the problem, while you seem to prefer the small scale parts. Maybe we wwould make a good team.

I'm with you. I would also say refactoring, and rearchitecting can be fun. It's sprinting, and agile that really gets to me. I've considered moving away from the job.

To me it's a mix of passion and reality.

I am passionate about programming, even the parts you don't enjoy like rearchitecting and refactoring, those mean "applying knowledge to solve a problem" which I really enjoy.

I detest the bureaucracy around these (teams, requirements, deadlines, etc.), but those come as either life requirements (a company must make money in a reasonable manner), or the current status quo of your entire project and its teams.

The latter at least can be resolved by leaving your company.

I think I'm the opposite. I like solving problems as part of a team, evaluating different tradeoffs and approaches, figuring out what people need from the software and how to get it there as simply and cheaply as possible. It's very engaging with no easily identifiable "best" or "optimal" in most cases.

Actually dealing with code is a pain in the ass. It's better than digging a ditch for ten hours a day but not really enjoyable for its own sake either.

Processes are the norm at large corporations, but less-common to non-existent at startups. I'm guessing you're working for the former rather than the latter.

Most of the software engineering jobs have the same process you described.

But if you are into putting together new projects, possibly you might enjoy working at small consulting companies who are into building prototypes/MVPs.

But if you join a company at post MVP, you might not get what you enjoy doing.

Optionally, there will be some pure R and D jobs, which may not have the same processes that come with software engineering but you might have to read a lot of theory though.

It's hard to be helpful because I find this a bit like saying "I want a job where I can cook cool new food but not do the washing up."

You're more likely to get this being a contractor or at a small company. Most of it's going to be a matter of asking the right questions though - you probably want to have some well defined area of responsibility and not have to work with anyone else in it.

I find the opposite. Analysis, requirements capture and design get you to the point where programming is required. But it's the least interesting part of the process.

I don't consider Agile as software engineering it's managed hackery intended to keep people sprinting until they drop.

Programming as an aspect of analysis is however fun.

I would suggest looking for software engineering jobs outside of SV (if that where you are and can) and outside the software industry.

The best thing I did in my career was move the hell out of SV and started working for a manufactoring company building internal tools, scripts and programs.

It will be hard to find the perfect job, but you will probably have a better chance outside of SV where every company tends to be a copy of one other internally.

Honestly, I might recommend looking for an entry level job in an industry outside of software that has somewhat struggled to keep up with the changing times. Find a company where people are manually transferring data from one spreadsheet to another, or where there is a huge backlog of data in need of processing with some manual step that can be automated. Write one-off scripts that will seem like magic.

I feel this, but maybe a little different. I love programming, but I don’t love all the framework stuff that you end up constantly managing in a more mature app or the initial set up of all the dependency stuff overwhelms me.

Figuring out why some cloud formation stack BS isn’t working just isn’t fun to me. I prefer the kind of work where I can solve the problem by surfing through the actual code and figuring it out.

Substantial software engineering jobs tend not to do "sprints" and no or limited "agile". You still want to always be learning.

I hate both programming and software engineering, but I love money, flexible work schedules, and no risk of falling off a roof while on the job.

To be completely honest it sounds like being a trust fund baby is the right "job" for you.

It sounds like you just want to stay in your comfort zone, not do anything that your don't consider "fun", and don't want to learn anything you're not comfortable with, and don't want to think about the future or any of the rest of your company.

The corrupted forms of agile—which are so pervasive that they're now what most folks think agile is—have definitely make the experience of being a software engineer worse.

Some of what you're describing can be found in for-hire firms that build out software to spec for other companies. The risk (for you) there is that, sometimes, you might have to learn or use new tools/tech.

I love programming and I love software engineering. What I don't like is having to work for a living(in this case, doing SWE).

Ha, I love programming and bug fixing, but I also love refactoring and rewriting. I even love writing unit tests. I can’t say I care much for the “estimation” part of software engineering, because I don’t believe it’s a realistic goal - or, at least, I’ve never met anybody who could do it. (I’ve met lots of people who insist that I have to do it though).

I have found SDET type roles to be good.

At least where I have worked testing is just as process and meeting driven but the meeting are focused on test coverage not the test tool dev aspect. So I get to hack together new test tools in whatever way I like. The only process bit is I have to document how to use it well enough that someone else could run the test case.

Yes.

Although I'd argue that refactoring and rewriting are part of the programming fun.

"sprint", "agile", design docs, red tape, bureaucracy, policy, and meetings are the crappy part.

I just want to write code. I will work on the most boring problems. I don't care. Hard or easy. Features, infra, whatever. Just let me write beautiful code.

Unfortunately you are saying "I like doing the fun part of software but not the not so fun." Maybe look for a company that needs or uses software to enable their product but does not sell software or software services. Or find an area where software is not well established and is just beginning to be integrated into the business.

Wow I am exactly the opposite. I do not like hacking. I like designing and optimizing and experimenting with new languages and strategies.

I have mad respect for people like you, and always wished I was able to think in your way better. You should find a startup that has an engineering team that will complement (not mirror) your skills.

The fun part is mainly dependent on the leaders and culture. If they are serious about agile then you finally fit/assimilate into that work style. But without opportunities to communicate, like for e.g. constructively discuss or debate, things will start to appear stale. That is where I think the excitement takes a plunge.

I am the opposite. With time I have grown to be rather neutral and maybe slightly negative on the topic of programming and CS, but I love solving real-world problems and producing working solutions. I am content with having to program in order to do that, but would definitely skip the programming step if I could.

I’ll just say that a lot of jobs don’t follow the exact agile sprint methodology. At my company we have weekly sprints which are just rough lists of what each of us will do, and there’s no pressure to do more ever. And if I can’t do something one week I just add it to the next week’s sprint.

It depends on how do you define software engineering? For me, software engineering is what allows us to do programming on scale. Programming is sure fun, but on its own, its very hard to scale beyond one person. If you want to distribute and delegate tasks, you'd need software engineering.

You need to find an SRE job, it involves lots of what you enjoy and a lesser dose off the architecting things.

Programming can be many things. I don't particularly appreciate finding or fixing bugs, or unit tests, incidence response. Very rare breed of programmers do these for a hobby. But you know what many more people program/code for a hobby? Games, graphics development. I love that shit.

I prefer many small projects than big ones. Because complexity grows exponentially but payment and fun don’t

Not everything in life has to be "fun". Sometimes important things aren't fun to do, but we do them because they are important.

Seeking endless fun is vain and meaningless. Doing meaningful work requires discipline and perseverance, it won't always be fun but it'll be more satisfying.

As a junior software engineer, I think the same but perhaps I have come to the conclusion too early. What I know is that I want work to always be easy or maybe with slight difficulty, and keep the hard stuff for personal projects. That way I wouldn't feel much stress.

This resonates with me. If I had to sum it up.

I just want to build cool shit that solves problems. It's fun.

I love fishing but could never be a fisherman. Jobs are not fun, but more like temporary slavery.

I hate you, but I love having sex with you

I’ve always enjoyed “programming in the small” more than “programming in the large”, especially when the latter is in a position where I am part of a huge machine shipping a huge product to a large number of users, which has been most of my career.

To me, the cult part is the worst in this industry. Job market is rotten and it spreads to how programming is adopted. In short, cult -> demands of mediocre tools -> supply of idiots. Apology if the tone is too extreme to this post's theme.

University manages to sap my enjoyment of basically everything related anything, but I'm fine doing refactoring, rewriting and rearchitecting in my own time. Never really been employed, so not sure if sprints and agile are ever fun.

RE: Finding and fixing bugs is a lot of fun

In that case I suggest finding a commercially-backed, open source project which you are passionate about. You can have best of both worlds - plenty of bugs and community interaction, all while also making a living out of it.

Play store tirar todos os dias gigantes

9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999990999999999999999999999999

We can’t go through life just eating cake all the time. We need to eat vegetables too.

I have a similar feeling but I've distilled it to something a bit different. I love programming where my human dependencies are motivated, smart and aligned. If any of those three are low or zero the fun can only last so long.

I think 'software engineering' is a misnomer. It's basically just like any large project, lots of fuzzy knowledge, swerving constraints, human group dynamics, quality check... The coding part is .. minimal.

Try an early stage startup? Might be some super lean process in place -- maybe very light scrum, not even. Usually it's just "do this thing" -> ship it -> on to the next thing that sticks.

What you are describing is:

Hobby vs. career.

You basically want all the fun creative parts without the process and review and maintenance required for a product that has responsibilities.

It's like building a shed in your back yard vs. building a skyscraper in a city.

How can a stifling, boring software engineering process be changed into a fun programming process?

This is a question that came up a number of times when I worked at a company where the developers were not enjoying working there.

I find myself spending most of my time writing tests for my website. It's grueling and I hate it, but it's basically akin to eating my vegetables, as I would be completely lost without them.

Don't get promoted, an entry level dev does this pretty much all day

Come join us at Upmortem. We're working on an AI slack bot. We cut all the nonsense out. No stand-ups. No people on call. Just pure development. Email me at nlake44@proton.com.

I prefer to use term "programmer" to describe to people who I am, rather than "software engineer" etc. And because programming is what I truly love to do.

Even though, in my resume I use Software Engineer/Developer of course, because "programming" does not bring you money.

Why so? To be honest, I think that we, the programmers, rarely make real things. Real developers make buildings, software developers do not make anything real rather than text on computer screens.

In its root the purpose of programming as a job was developing programs that would automate processes of real economics. E.g. to automate industries(manufacture lines) or maybe to optimize transportation logistics. Today's economics is post-industrial economics. Basically, the economics that focuses on control of human attention and selling this "control" to other actors. Computer technologies is a big part of it, but it is loosely connected to automation.

Only a limited number (a big number, but still limited) of people are capable to program. This is quite specific kind of mind. And only a small subset of programmers are capable to think in terms of programming and in terms of how to influence other people (the true value of post-industrial economics) at the same time. So, the ordinary programmer, to be honest, does not fit well in this system.

On the other hand there are a lot of people who can't program, and they loosely understand computer systems, but they are good at the art of spreading influence. These people are primary agents of post-industrial economics, and they are truly rule this system. They occupy high positions in companies and corporations, and they spread their way of thinking and ways of management to other minorities (including programmers).

We, the programmers, have to deal with this situation somehow if we want to have our part of the economic pie. Perhaps, through the trade-offs and compromises. But we have to admit that we are only minor cogs in this system. That is how it is in the current Economic Formation.

Looking for better jobs in companies that value pure programming would inevitably imply of looking for companies that don't perform well in the post-industrial economics.

The solution that I see is to do an ordinary "software engineering" job the way the rulers of the System want us to do it, and in the way we don't like to do it. At the same time we can working on the stuff that we love, and in the way we love to do it solely (or maybe with cooperation with other programmers). This is the best practical compromise that I can think of.

Scaling things- i love hacking away at my own ideas and my own little projects that only I will use.

The requirements to make things scale- Being part of a team with procedures and processes kills the fun for me.

Liking software but hating software engineering is kind of like enjoying the platonic and hating reality.

We're all in agreement that the real world is messy and stressful to deal with. That's life!

> What are some good jobs for a person like this?

Academia, using programming in another science. You can program all you want there but you never have to do anything like software engineering.

Quite the opposite. My happy place these days is working with higher level problems surrounding architecture, planning and the people behind the code.

That's why I switched to management.

Huh, I find that I like a lot of the things that you hate. Refactoring and rewriting can be tedious, but it’s a hundred times more fulfilling than fixing bug #39004.

If writing tests is fun for you, you could theoretically accept a position that is writing tests and fixing bugs all day long. Pay is a question of course.

> I am not too keen on learning new paradigms or languages unless I have to.

Not the attitude I'd expect from someone that claims to "love programming".

Not a job, but you might be interested in https://www.recurse.com/

Software development in a research setting might suffer from too little process, but I imagine would be a breath of fresh air to you. It has been to me.

This is what we used to call a "code artist"

The money ruined everything. It spoiled San Francisco, the tech culture, polluted the industry with people passionate about money instead ... I'm not saying people shouldn't get paid, but if the richest tech person was #400 on the Forbes list and not known outside the industry as opposed to roughly half of them, I think we'd all live happier lives, including the Musks and Zuckerbergs of the world; they seem miserable. It's not in a healthy state.

Perhaps you don't enjoy working for a software engineering organization. When the organization is concerned about methodology as opposed to getting the result, that can be a problem. Too often, I've been in organizations that found a new trend but never asked if it actually mattered. That being said, methodology does matter. We've all been around someone who just threw something together, it was our job to clean up the mess :-)

How do you find and apply for jobs like this.

Bug hunting mercenary would be my ideal job. Not sure how to find jobs that have that need.

It sounds like you'd enjoy academic/research programming. Programming for business does not seem to suit you.

Refactoring is so much fun, get outta here

I'm late to the party, but I recognize this all too well. I became a (SE) teacher.

After 35 years, software engineering remains a moderate challenge but programming is no longer interesting.

You would probably love being an independent security researcher if you can make a living off bug bounties.

I love software engineering AND programming. But too often working "in software" involves neither.

I'm definitely a hacker/artist type vs engineer. I like shipping things, stumbling around, finding a path, not planning them out and executing that plan. By the time I've planned something I have to use all of my available executive function to force myself to do it.

So I tend to gravitate to early startup life where it's all chaos and unknown and getting things done quickly is most important.

Yep. I'm sure there are comlabies out there that don't suck, but I haven't found them yet.

This. I hate Xcode and all the dev tools built by Apple, but I enjoy writing software in SwiftUI.

I just hate the interview process and working with antisocial teammates, love everything about the field

Do you hate catering but love cooking?

I empathize and completely agree; I like the distinction made between programming and 'software engineering'; the latter is all pure fantasy driven by the profit motive. I think we've been too nice to capitalists and need to reclaim our hobby from the evil. I'd so like to work in a well organized coop of some sort, on interesting challenges, damn the profit motive.

And agile can go burn in hell, however 'correct' you are doing it.

Similar non-sequitur: Do you hate automotive engineering but love wrenching?

Software engineering != Programming Software engineering != CS Programming != CS

This is what we used to call a "code artist"

A good job tends to be one not in software

I'm the opposite, haha. I guess that's what makes good teams tho!

I love taking existing code and making it better while adding functionality.

all of the things you listed are included in the software. and they all serve the same thing. to maintain the software. you should focus on the purpose as much as you focus on the process.

A big tech company SWE, just join the Quality team, rather than Infra

You could get into another field of programming, AI is coming up.

Devops is what I hate.

Switch to firmware dev-t. It's still tolerable.

Programming ought to be called software engineering.

You’re not a programmer, you’re a hacker

I like refactoring to make it look more elegant.

For me it is usually quite the opposite somehow

I hate the egos fight. Love programming <3.

I like all the things you don't like!

I like both those things. I hate people.

How come refactoring is not fun??

This is why I work at startups.

My comment on this article.

Junior Software Engineer

Unit tests are not fun

the other way around

SRE?

Same here…

Absolutely.

You can try

- Education

- Tech evangelism

Yes, I have come to have a hatred towards software engineering. I will probably always be a software engineer because it's still a better job than many, and because I like programming. But holy hell, there are so many problems with this profession and a real lack of interest within the industry in terms of actually maturing it.

Pretty much every problem an engineer deals with on a daily basis is either self imposed or imposed by other engineers. Most of the problems aren't even real problems because most real world issues have already been iterated upon. Most of what we do is fixing our own mistakes. Being a software engineer sometimes feels like being a self-licking ice cream cone because, if it weren't for all the new frameworks and the lack of effective team organization, a substantial fraction of us would have nothing to do. Well, besides hobby coding, which I guess can be a good thing, but I don't even know that many programmers who actually code anymore as a hobby.

What needs to go away are most of the paradigms that still get pushed around.

The tools themselves are actually pretty good. We have speedy JIT languages, package managers on every OS, no more Internet Explorer, awesome free IDEs, and more help and documentation than ever. What's gone horribly wrong is believing that we need more tools for every task domain. A mistake we've made is believing that X is "considered harmful" and to only apply the "best practice" in every nook and cranny no matter how insanely complicated things become. We've made the mistake of believing every problem is a matter of scale and almost never poor engineering. Poor engineering? Impossible! That is unless it's that of the guy who came before me and left the company.

I can go on. Why do we still use frAgile methodologies all over the place when no one can adequately measure whether it's more effective than another workflow? Why is it that every single company I work for ends up using Scum methodology but never bothers actually measuring whether performance improved as a result? Why are we so opposed to documenting our work? Why do we keep bending over backwards to make websites behave like applications and still screw it up most of the time? Why are we obsessed with code coverage when it's only weakly correlated with the number of bugs that manifest? Must we keep adding more and more lint rules?

To top it all off, it doesn't matter what you think unless you are one of the 10% that has a real say in how a codebase is going to take shape. The reality is most software engineers have limited capability to take the initiative for change.

But hey, it's a good profession no matter how crazy it can drive you sometimes. I'm not saying people should do it forever, but we can do a whole lot worse.

At the same time, we ought to be doing a lot better. With the exception of AI/ML, I believe software engineering is in a bit of a dark age.

yes

It sounds like you like easy problems and don't like hard problems.