571–580 of 733 posts
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.
Earlier quoted context omitted.
I think the real "unicorns" are * Small/medium size companies where you recognize most everyone even if you don't work with them. There are enough people so you don't have to do things you're not qualified for like in the very early days of a startup. * Steady growth, but not crazy, venture fueled moonshots. * Selling something that earns enough money to grow the business in a fairly organic way. I worked in a place…
I’ve worked at 3-4 small companies (less than 30 employees) and I’ve never been happy. There is always 1 person that makes my life miserable (constantly rejecting my ideas, ego is larger than their experience level, etc). I’ve worked at a 100, and two 1,000 engineer count companies and I never met any “coding princesses” in those roles. I think part of the problem that triggers this is in small companies, one enginee…
Earlier quoted context omitted.
I’ve worked at 3-4 small companies (less than 30 employees) and I’ve never been happy. There is always 1 person that makes my life miserable (constantly rejecting my ideas, ego is larger than their experience level, etc). I’ve worked at a 100, and two 1,000 engineer count companies and I never met any “coding princesses” in those roles. I think part of the problem that triggers this is in small companies, one enginee…
Are you ideas normally implementable in the next month or something far-fetched? Try to come up with ideas that are low hanging fruits, easy to do but have a high value. I don't think any company/management in their right mind would constantly reject "good" ideas that ultimately result in more revenue. The ideas I see being rejected are either too far out there or some "dev utopia"-kind of ideas that don't bring in m…
We must have worked at very different places.
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 p…
It almost works except that no one really understands the problems you're presenting because they've all got their own problems to deal with. It's more helpful as a duck.
Earlier quoted context omitted.
> I can almost guarantee that you’re just at the wrong company. Even if this is true (which it most likely is), there's no guarantee the company you move to (in your quest of finding "the right company") won't either a) also be the wrong company again right off the bat or b) become the wrong company again. I've kind of just given up. I've accepted I'm basically a "technical plumber". Take data from this system/vendor…
Yeah, the older I get, the more I'm able to see how companies could be so much better, so much more effective. But that's not something executives really want most of the time. So I think what will eventually drive me to retire is not getting tired of making things, but an inability to put up with the gap between what's possible and what's actually going on.
If I had to make money by coding, this all would be gone.
So: do another job and code for fun. :)
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 p…
Would it help if, as someone on the other side that for the most part only plans as the feature is discussed on their head and then jumps into code, I say that the code is where I "document" my plans as types, comments, tests, and stubs, which I progressively expand into implementations? On the same vein, I'd add that some languages greatly facilitate this process, while others make it more of a pain.
Earlier quoted context omitted.
What is actually Agile then, and how does one actually practice it?
/u/lr4444lr and /u/ajmurmann nailed it. "Agile" is just what the Agile Manifesto says. Strictly speaking, "Agile" in and of itself isn't even a methodology - it's just a set of principles, to which a number of concrete methodologies claim some association. They differ in the degree to which they faithfully represent the spirit of the manifesto. So really, you're never "doing Agile". You're "doing $X" where $X can be…
Earlier quoted context omitted.
I think the real "unicorns" are * Small/medium size companies where you recognize most everyone even if you don't work with them. There are enough people so you don't have to do things you're not qualified for like in the very early days of a startup. * Steady growth, but not crazy, venture fueled moonshots. * Selling something that earns enough money to grow the business in a fairly organic way. I worked in a place…
I worked in a place like that and it was awesome. Unfortunately we were so good at what we did across the board that we got bought by another company to integrate into their larger offering. It made a lot of sense from a business perspective but the tech team in our office was made redundant and so my time there came to an end. I think this is the inevitable conclusion to good, small companies. Since it actually work…