Your claim is common, but wrong. Approximately none of the major technology companies do more than rudimentary call-center service for bug reports from consumers.
If anything, the entitlement you express is counterproductive, because sometimes people like you convince open-source developers that their time is better spent catering to your sense of entitlement instead of their software.
Source: I am a maintainer of several projects. Some that are used extensively. And I take bug reports seriously, even if I can't always get to them right away.
"it's free, go away" is a real problem. Denying it won't make anything any better or help FOSS get adopted for anything other than servers.
I have experienced it many times before, and almost every time I've gone back to propriety software and breathed a sigh of relief.
Your source is inapplicable. You are not a statistical universe.
Also, "it's free, go away" is a straw man, because the "go away" part is also nearly universal within proprietary software. Try opening a ticket regarding a bug in Word, or AutoCAD, or so on.
The real difference? Those closed products also have closed bug trackers, so you don't get to see all the times users were ignored or told to pound sand.
No, it's like telling the candy maker that their candy made them sick or otherwise left something to be desired. If the candy maker cares about making good candy, that can be useful information, even if they may not have time to do something about it. If the candy maker cares about making mediocre-to-bad candy freely available, then they will say "it's free, go away."
No, it is exactly as i wrote above, the idea isn't to complain back, it is that you get shit for free and you have no standing to demand for anything more than what you got. If free candy makes you sick maybe next time do not accept free candy from strangers, hm?
(of course i knew someone would try to reply with a "No, it is like <insert post ignoring the point here>" but decided to go with it anyway)
FWIW i am not a FOSS zealot. If anything some of the software i find enjoyable to use is not FOSS (but sadly a lot of it is older software, largely because of user hostile modern trends - see Electron, phone-home DRM, adware, etc - but also because newer versions or alternatives simply have worse UX and/or bloated to almost unusability) and really my comments come more from a "you are entitled to what you pay for" stance.
I certainly won't disagree with hostile modern software trends. I just think if FOSS maintainers are accepting the responsibility of maintaining the project, they should accept the responsibility of taking bug reports seriously. Everyone knows they are no fun. And everyone knows they aren't flashy. And the maintainers are more than welcome to ignore them. But in doing so, they can't complain about people not accepting consumer facing FOSS. It's a package deal.
People are not a hive mind, some developers may ignore bugs, others may complain about end user oriented FOSS acceptance and perhaps some do both, but chances are these two groups are separate (and in larger projects you may even have people under more than one of these groups).
Also unless someone has explicitly expressed they are taking such a responsibility you describe, such a responsibility only exists in some people's minds. A lot of programmers want to share free stuff they made and stop there.
Roslyn is the compiler. There's not much of a debugger in it, is there? I mean, I guess the debugger will use Roslyn to parse watch expressions and evaluate things in the Immediate Window, but beyond that I think debugging is handled by something else.
Now do that for a month. Or even a week. You may be more productive bc you don't want to be seen as slacking off with someone watching, but maintaining that kind of pace is untenable. Did you ever get stuck and check your email or Facebook just to give your brain a little break? Did you ever sit, unsure of your next move? Or did you do the first thing you thought of, even if it was wrong, so you didn't look like you were wasting time?
Intense productivity with someone looking over your shoulder is great for a day. After a week you'll want to quit. After a month you'll want to kill yourself.
I don't believe this is the case at all. When I was in university, everyone I know (including myself) organized into study groups precisely to combat procrastination, and not for any intellectual benefits. It worked. At the end of a day of solo studying, you would feel horrible and ashamed because you got so little done. But at the end of a group study session, you actually feel fulfilled.
That's one way to see it. Another way is "I've shown that I got some unleashed productivity potential. How can I make it sustainable rather than an exhausting sprint?". In other words "how to make it a habit", habits are easy to sustain
I'm not arguing for having a stranger watching you all the times or that you should only think about productivity, just that it shows that there's a margin for improvement that can't be dismissed
I don't think this approach necessarily helps with that distinction of good breaks and bad procrastination. I think it would be interesting to distinguish those, but I would look for another method if that were my goal. That also isn't to disregard the interest of the experiment above, just to say it doesn't help here.
That’s fine. Having a tool I can use a few hours a few week to get me through things that are the highest product of important and annoying is super valuable. Doesn’t have to be a lifestyle.
Normal office environments already have managers that are plenty capable of watching and critiquing everything you do all the time, but at least in my experience, that's almost never how it goes. Good managers know that freedom and autonomy are empowering. I'm sure others have had much worse experiences, but I think it's mostly well-established that micromanagement is a bad thing.
Whether it's in-person or with a tool like this, if your employer is creating an unreasonable amount of pressure/stress, then that puts them in a weaker position in the job market than companies that treat their employees well. Give them feedback, and if they're not receptive to feedback, see if you can ask for a raise or find another job.
> Good managers know that freedom and autonomy are empowering. I'm sure others have had much worse experiences, but I think it's mostly well-established that micromanagement is a bad thing.
This is really important. If your manager or PM is constantly bothering you, you won’t be able to get into your flow state, which is important in software engineering.
that's what we use daily standups for. i announce my plan for the day, and the next day i report on how well it went. if i procrastinate to much i have nothing to report.
it doesn't impact my freedom and autonomy because i decide what to do every day, so i set my own goals and only report on how well i achieved them or explain why i didn't (run into a bug etc)
this is not much different from pair programming.
even pairing with a junior developer where i do most of the work myself makes me more productive.
pair-programming is also exhausting. after an 8-hour work day i am beat. however i can't think of any better way to work, and it it is practiced in several companies successfully.
if people would want to quit after a week or kill themselves after a month of pair programming we would see a lot of backslash against it.
We pair programmed more than 90% at my last job, and it was great. Together we would typically come up with architecture, design, tests and names which were better than either of us would have done on our own. It is hard work, but very rewarding, and it has many pitfalls and nuances which we tried to work out at our ~fortnightly review sessions.
More important than pair programming itself is the willingness to look at what works for the team and how you can improve the experience and productivity together. Most of the time we did traditional pairing, with two keyboards and mice on a dual-monitor PC, and simply signalled each other when we wanted to take over or cede control. Towards the end of the four years there we very successfully "mobbed" on some complex problems, and split up when we had worked out what to do next. We would typically work in different pairs every day, which resulted in everybody knowing the entire system to a similar degree — we didn't even need a handover when someone left, and onboarding basically meant that the more senior employee had to explain a bit more of the context while pairing with the new hire. I found it did wonders to my understanding of how other developers think and especially how to explain my thinking to someone else. But YMMV, and good luck!
>> if people would want to quit after a week or kill themselves after a month of pair programming we would see a lot of backslash against it.
That's been my experience. Even at the few places I've been were some do pair programming it's a very rare occurrence. Occasionally upper management will stump for it, likely because they (a) don't actually program all day and (b) see it as some sort of kale-like super habit. None of my IC have ever pushed hard for regular sessions.
Maybe. On the other hand, the human animal has a powerful capacity to decide that whatever it’s doing is the good and right and normal thing to be doing. After a month you’re just as likely to be completely acclimated as you are to be suicidal.
There’s also the element that when a stranger (or a subordinate) is watching you don’t just act busy — you act like you enjoy your job, you show off a bit. This is the kind of performance that soaks into the skin and becomes real.
I find that pair programming has the best of these benefits at the same time reducing the probability of feeling suicidal etc. Personal experential bias of course.
I'd imagine that after a week you'll start checking email (because that's still work, right?) and after a month you'll be on Facebook because really, who cares about some stranger knowing you're procrastinating?
Pretending Canada or Iceland or Norway are some kind of utopia where everyone is rich, in perfect health, eats pixie dust, and shits rainbows isn't doing anyone any favors.
Those countries have their own problems, even if they aren't the same as in the United States.
Different cultures, different economies, different priorities.
You can't solve a problem by saying "look how awesome this homogenous country with a population the size of a medium sized US city is!".
That argument will always fall flat on it's face. And on deaf ears.
Certainly we can and should learn from other countries. But it's getting really tiring to hear these empty arguments trying to hold some other country up as some kind of wonderous Paradise when it's simply not true.
As a Canadian, I hear frequently from Americans that Canada is a homogeneous place. I imagine there are a lot of different ways to measure that, but for what it's worth, per StatsCan Canada has the highest foreign-born population in the G8[1]. Subjectively, Toronto feels amazingly polyglot compared to most large US cities I've spent time in. (Although, as in the US, there's a lot of geographic variation.)
Not to invalidate your point, but that particular assumption always strikes me as dubious.
That and difficulty introducing new developers to Ruby projects. When so much metaprogramming and abstraction is used, and everyone creating their own DSLs, developers often have to learn new languages every time they are brought on board to a Ruby project. It basically defeats the point of "convention over configuration" in Rails. Rails is fine on its own, but what Ruby allows people to do creates these "elegant" messes that end up being more difficult to learn, requiring people to become "experts". (which I suppose creates job security)
Don't even get me started on how lots of Ruby developers don't believe in documentation because the expressiveness of the language makes their code "self-documenting". (i.e. their shit doesn't stink)
I actually love Ruby, but I've learned to avoid the advanced features unless they make perfect sense for the task at hand. The Ruby culture, however, is what caused me to appreciate JavaScript; the fact that it contains a simpler set of tools makes the language more readable IMO, despite it being less English-like, and I find today's JS projects much easier to understand than almost any Ruby or Rails project of even modest scale.
you were either burned really hard by metaprogramming gone wrong or you've actually never seen it done properly.
there is a school of thought that says in some cases you should not shoehorn the problem you are trying to solve into <insert your favorite programming language in here>. In cases like that having a DSL (which does stand for Domain Specific Language) is worth its weight in gold. Focusing on expressing the problem in it's own domain language is beautiful. Ruby just happens to be awesome at building DSLs.
to your point about "elegant" messes: you can create a mess whatever tool/language you want. the language is not there as guardrails. I agree with you that less is more and in most cases you don't need some of the uberpowerful features, but when you do, the way you solve the problem is absolutely beautiful.
IMHO, Ruby code is the closest to code poetry that you can get with a vanilla/for the masses programming language.
I've seen it done properly, it's just that the majority of the Ruby metaprogramming I've seen is completely unnecessary. I'm sure it's God Mode to a lot of people, and the powers of God are difficult to resist.
DSLs can be great. The problem I have with DSLs in the Ruby world is that it's too normal to just whip up a DSL for things that don't require it. A good example of a DSL is RSpec, which has a very specific goal in mind and is well documented. A bad example of a DSL is one that Bob the developer created for a Rails app at Acme Corp., which is sparsely documented because Bob is a busy guy and there's a lot of tasks in the backlog more important to stakeholders than documentation. Said Rails app at the end of the day serves webpages, and somehow the business logic "required" its own language built by one or two people who couldn't dedicate enough time and thought to the design of the DSL; it was built pragmatically, and down the road when Bob quits nobody is going to want to touch it because the methods defined in the DSL have their tentacles in everything. In the best case, Bob actually wrote tests just for the DSL as well as the business application itself.
You are right in that a mass can be made using any tool. Where I disagree is where a language can act as guardrails. Guardrails might not even be the right term. What I do believe is that, a great deal of the time, the most powerful tool isn't necessarily better than the simpler one. Someone learning to fly probably shouldn't be given a fifth-generation fighter jet, as a much smaller aircraft would allow them to fly sufficiently without the complexities I'm sure there are in operating a military fighter jet, despite the fact that the fighter jet can do "more". Even an experienced aviator probably doesn't need to be flying a fighter jet for their purposes.
Ruby, IMO, is a lot like a fighter jet. Yes, it can fly from A to B, but it's can evade radar, has a machine gun, and do maneuvers other planes can't. Other languages might not have those other things, but that prevents less disciplined pilots from the temptation of doing unnecessary things that can result in mistakes. Sometimes you need a fighter jet, but most of the time we're not at war.
Everyone's experience is different, and I'm not saying your point of view is invalid, but I just feel different personally. I really wish people wouldn't use Ruby like they're a fighter jet pilot all the time. As someone who attended a coding bootcamp, I would like for bootcamps to emphasize hesitance around writing DSLs and metaprogramming rather than pushing those concepts on to junior developers as if they are the duct tape that applies to all problems.
The entire point of the original article is that Google's constant killing of products makes everyone fear what will be next, bc even seemingly popular products get killed off for little to no reason. The entire point of this article is that Google's own actions are fanning the flames of this speculation.
I see from another comment that you’re struggling with a difficult-to-maintain Rails codebase, but this comment is needlessly contemptuous and risks making you seem arrogant. It also sounds like the kind of thing that some smug, newly-converted Ruby/Python programmers would say about PHP (I plead guilty on behalf of my 10-ish-years-ago self).
I haven’t seen anyone call Ruby/Rails a "language/framework for non-programmers". Nobody asserts that someone can or should try to build a professional-grade app or site without having a solid understanding of programming fundamentals.
It’s just a matter of what you optimise for.
Rails makes sense in startup land, where it’s more likely that not that what you’re building won’t turn out to be popular, so it’s best to test the concept as fast as possible to avoid wasting any more time than you need to.
You can easily rebuild in other languages if you’re lucky enough that scale, performance and maintainability become major problems. I’ve seen that happen at several companies including Twitter and Airbnb, and it makes perfect sense.
Microsoft, please make one for Ruby! C# vet and lover of VS and VS Code, now working on a legacy Ruby/Rails code base and hating a new life of lifecycle callbacks, fat controllers, fat models, magic methods, and un-upgradeable gems. Ugh.
Rails has so much metaprogramming that static typing isn't really going to get you very far. Type checkers and linters won't know what the hell is going on.
+1. ruby is by a good degree the hardest language to statically analyze that ive ever worked significantly with. type anns fit python relatively well due to it's philosophy being pretty much the direct opposite of ruby's: "explicit > implicit" vs "having a conversation"
Django has quite a lot of "magic" as well. There is work being done on a mypy plugin to support this magic in addition to type stubs. It is already quite usable and supports type-checking many common patterns: https://github.com/mkurnikov/django-stubs
Django and django rest framework make such a heavy use of metaclasses that I gave up on using mypy for a Python project. My code was littered with annotations and stubs and it still wasn't catching obvious type errors, and I had to fall back to use `Any` in way too many places. Couple that with the horrible typing syntax and the fact that mypy was slow, kept crashing with segfaults and often wouldn't even signal type errors on fully typed functions, and the result was a lot of effort for almost no gain.
If I compare that experience to when I switched from JS to TypeScript, it's like night and day. TypeScript is designed to work well with development tools and already existing libraries, while Python's static types feels designed by someone who never worked with static types while completely ignoring code patterns used in existing libraries.
It's a shame Crystal isn't taking off that much, I use it for some personal projects and it's such a joy to work with thanks to the static typing, unfortunately the community is a bit too small. A static-typed ruby is just the best thing I can wish personally.
Companies like Microsoft, Google, and Facebook are huge open source contributors specifically bc they can get a return on their investment. While your intentions may be noble, I think you'll find that more restrictive licenses will have the exact opposite effect and open source projects and contributions will be quickly whither and die.
Open source was never about preventing people from making money on the works they create, it is about preventing companies from telling people what they can and can't do with that code. It is about insuring forward progress and the ability to build on what other people do, making it better, and ensuring that that future is not meddled with. Or restricted.
And there are plenty of licenses that accomplish that, the GPL and it's offshoots chief among them.
FOSS Zeolots: everyone should use FOSS! Micro$oft is evil!
Also FOSS Zeolots: Oh you have a bug? Screw you. You're getting it for free. Stop complaining. I'm busy making a new icon.
OSS is great. But until this attitude is killed, it will continue to hover just above "who gives a shit" for anything other than developers