Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Cloud Programming IT

Do Developers Benefit From Fewer Choices? (infoworld.com) 108

"Enabling developer productivity has become a key vector in every organization's success," writes Matt Asay at InfoWorld — not a nice-to-have feature but a must-have.

"Which is why, perhaps ironically, the best way to set your developers free may actually be to fetter their freedom." The more developers mattered, the more everyone wanted to cater to their needs with new software tools, new open source projects, new cloud services, etc. This meant lots of new developer choice and associated freedom, but that wasn't necessarily an unalloyed good. As RedMonk analyst Steven O'Grady noted in 2017, "The good news is that this developer-driven fragmentation has yielded an incredible array of open source software. The bad news is that, even for developers, managing this fragmentation is challenging."

Can one have too much choice? Yep.

It's long been known in consumer retail, for example, that when there is too much choice, "consumers are less likely to buy anything at all, and if they do buy, they are less satisfied with their selection." Turns out this isn't just a matter of breakfast cereals or clothing. It also applies to developers building enterprise software. InfoWorld's Scott Carey writes that "complexity is killing software developers." He's right. But what can be done?

In a conversation with Weaveworks CEO Alexis Richardson, he related how self-service development platforms are reemerging to help developers make sense of all that open source and cloud choice. By giving developers "a standard, pre-approved environment in which the effort to create an app from an idea is minimal," he explained, it allows them to "focus on innovation not plumbing."

"Done right, a little bit of constraint goes a long way..." Asay argues, touting the benefits of PaaS (platform as a service) self-service development platforms. ("Enterprises that want to give their developers the freedom the cloud affords can couple it with just enough constraint to make that freedom useful....")

Asay argues that "However you approach it, the point is to stop thinking about freedom and control as impossibly opposed. Smart enterprises are figuring out ways to enable their developers using self-service platforms. Maybe you should, too."
This discussion has been archived. No new comments can be posted.

Do Developers Benefit From Fewer Choices?

Comments Filter:
  • FFS YES PLZ (Score:5, Interesting)

    by Arethan ( 223197 ) on Saturday April 09, 2022 @11:41PM (#62433326) Journal

    Please stop us from accepting every-language-under-the-sun. There are many, and trying to support them all is an absolute nightmare. My motto is, if you want to use an unapproved language, you'd best develop your own internal users support group, so you can all solve your own integration problems. If your thing manages to go into production (failure on your manager, but I digress), be prepared to spend the time/money to constantly fix it as the company core infrastructure continues to move forward while decidedly leaving your hobby behind.

    • And every source control scheme, flavor of scrum, ticketing system, and configuration management tool, to name a few of the already solved problems which waste months and years of work integrating with alternative solutions.

      • Python was a breath of fresh air when it was new in part because there was only one idiom for doing anything, even white space, and so everyone could read and understand everyone's code. Alternative idiomatic features and deprecations crept in and at first these did augment the expressiveness and ease of use . And unlike say C++ these where more thoughtfully organized. Rather than a toolkit of oddly shaped wrenches. But now we've reached a point where it's impossible to decipher other peoples code. Time t

    • Re:FFS YES PLZ (Score:5, Insightful)

      by narcc ( 412956 ) on Sunday April 10, 2022 @12:59AM (#62433420) Journal

      The problem is kids chasing the latest fad without giving a moments thought to the future. Well, that at the middle-aged guys chasing trends.

      Of the the most important, yet tragically overlooked, factors when choosing a language or other tool is stability.

      When I talk about stability, I have three factors in mind:

      1. It needs a good history. It should have existed for a while, 10 years at least, with good reason to think it'll stick around for another 10.
      2. It needs to have more than one implementation. You really don't want to get stuck trying to support a code base built on some vendors proprietary technology after they've abandoned it. I'm looking at you Microsoft and Google. Open source is nice, but it's no panacea. You need to ask yourself if you're willing and able to manage the project if the key maintainers leave.
      3. Changes should be infrequent and come with plenty of warning. Standards bodies are helpful here ... most of the time. (Some of them seem to think that they're not doing their job if they're not making frequent changes, no matter how stupid.) The good ones know that their job is to resist change and avoid breaking things when it's unavoidable.

      It's worth taking a few minutes to think about how your current preferred tools stand in light of these. I've tossed out things that I personally liked and haven't had a single regret yet.

      • by bn-7bc ( 909819 )
        Does c# fit into that category?
        • by bn-7bc ( 909819 )
          Ok replying to myself but I've forgoten something important when it comes to c#, Ignore microsofts apparent in ability to pick a GUI framework and stick with it, since the advent of .net core (later renamed to just .net) there are alternatives out there
          • by narcc ( 412956 )

            C# is a little more complicated because there are extra things to worry about. I'll try to answer as best as I can, though I'm not a C# expert.

            1) C# has been around a for more than 20 years now and while it's likely to stick around, Microsoft has abandoned .net framework. Fortunately ...

            2) ... There are multiple C# compilers and multiple .net framework implementations, though not everything is supported. The Mono project is the big one here, which is now also owned by Microsoft. It would be nice to have m

            • Huh?

              1) .net framework has not been abandoned, far from it (https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-framework)
              • It's not abandoned in the sense that it will still be supported on windows for maybe another 5 years, and then after that any major new versions of Windows probably won't support it, but meanwhile it will receive security updates until say Windows 11 is end of support.

                However, there will no longer be any feature additions as of the release of .net 5. So things like .net MAUI, which is basically going to replace/succeed WPF in the long run, won't ever see the light of day in .net framework.

        • by dvice ( 6309704 )

          > Does c# fit into that category?

          It violates the
          - "good reason to think it'll stick around for another 10", Silverlight perhaps the example that hurt mostly those who used it. There is really no guarantee. When Microsoft decides to end it, it will not continue. (yeah, some hobby project will still run the Mono but it will be just a sad shadow of it)
          - "It needs to have more than one implementation.", only one full implementation

        • by jmccue ( 834797 )

          Does c# fit into that category?

          At work just the other day in our group, someone asked for a Devl Joke. I forgot it, but the the punch line was "c sharp". It just got quiet. I then asked, does anyone here know what "c sharp" is. Only me and the person who who said the joke knew it was "c#". I guess that was was the real joke.

      • It had existed for a while, and was well established.

        Then I got so sick of it I just didn't care anymore.

        I feel myself heading in that direction with Python.

        Choice is always good. We are not children.
      • It's worth taking a few minutes to think about how your current preferred tools stand in light of these.

        All of these reasons are why I prefer Common Lisp even if Racket is all the rage these days. And probably a subset of C++20 over Rust, at least for now.

      • by Kremmy ( 793693 )
        Something I think should fall under this idea of stability is 'fit for purpose, does what it says on the tin.'
        You want the tech to actually do the thing you're trying to use the tech for. The big example I would bring up is ZFS. When ZFS was brand new, people were proselytizing about as hard as I'd ever seen tech proselytized. The problem came when I looked into the implementations of ZFS and found that all of the implementations were totally lacking the features that it was being sold on. ZFS did not do i
        • Comment removed based on user account deletion
          • by Kremmy ( 793693 )
            Solaris supporting all the fancy features of ZFS didn't do anything to help Linux ZFS support. The Linux ZFS driver simply lacked the advanced features. People were saying, use ZFS on your Linux and it can do all of these things to make these advanced setups simpler, you get RAID-like functionality built right into the filesystem, etc. Then you look at what ZFS on Linux actually supported at the time: stub.
    • Why are your architects, tech leads allowing you to use unapproved languages?
    • I personally prefer to use Rust for everything. Once you get past the initial learning curve, it's a really easy language.

      At my work we use Java mostly, because we maintain a vendor product that is based on it. We're not really a software development team though, more of an automation team (and thank god it's not fucking RPA shit.) Part of that means we already have precedent of calling CLI tools in many cases for integration with other vendor's products. So a lot of times I'll write something in Rust that

  • JOVIAL (Score:5, Funny)

    by parityshrimp ( 6342140 ) on Saturday April 09, 2022 @11:50PM (#62433340)
    Let's all standardize on using the JOVIAL language. It's got the math stuff from IAL, but it also has plenty of nifty features for systems programming and can drop to bare metal if required.
    • Instruction unclear; my homebrew washing machine is now ITAR-restricted.
    • by sconeu ( 64226 )

      I vote for either TACPOL or PL/1

      • by HiThere ( 15173 )

        I really liked PL/1. Of course, you needed the full languages, the subsets were a real pain. But I don't think it could compete with C++. What's needed is a real Python compiler, with optional typed variables to allow optimization. Cython could develop into that. (FWIW, I really, really, don't like Rust, but Vala and D have lots of good points.)

        (OTOH, I think the original post was trying for the worst language that wasn't intentionally bad, and for that I'd suggest APL. The original version, that requ

        • APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums. -- E.W. Dijkstra

          IBM made a couple of models of teleprinters that used a Selectric type ball. The APL\360 language character set included a number of backspace/overstrike combinations. To emphasize its character set edginess, the backslash was deliberate.

        • I was really just going for something old that could be used widely. PL/1 is another excellent candidate for that. Being something of a whippersnapper, I use C++ a lot. Coworkers give me grief: "Why don't you use python?", but I maintain that static typing and compiling to native machine code are good things.
          • by HiThere ( 15173 )

            Sometimes static typing is optimal, and other times it causes a lot of increased complexity. It depends on what you're doing. Compiling to native machine code is usually good, but not if you want the individual programs to be portable.

  • They start with something known from market research, which is fairly objective. Then they say, "It turns out," which normally would followed by an additional objective claim. But nope. "writes some guy." That's just an opinion. Nothing "turned out" to be a particular way.

    Do companies buy software because they were browsing around? Does the personal satisfaction of the purchasing agent matter? Or there is something else going on with software; is there a concrete problem that software is intended to solve?

    • Do companies buy software because they were browsing around?

      Yes, but it's worse than that. Executives at my company often come to me after being cold-called by some random software salesperson. "Do you think we can make use of this software? Would you please join me for a demo so we can determine whether it will work for us?" We developers already know the answer. No, it's just another BS solution looking for a problem to solve. Sometimes we can talk the execs out of buying the "solution", sometimes not.

    • by aergern ( 127031 )

      Reminds me of when I asked the group at work that works on our Confluence Wiki for a simple calendar widget ... the same one I used in Confluence that the last gig. Apparently, it's a "Premium" feature and I was told no.

      A fucking calendar is a "Premium" feature. Yeah, that answer did fill me with a lot of hate as far as using Confluence.

      • by narcc ( 412956 )

        I took a contract back in the early 2000's to add a feature that allowed users to print the reports their product generated. This feature was sold to their customers as an $800/seat add-on. I'd say I should have changed them more but they never paid my invoice.

        I just don't have that kind of larceny in me.

        I've often wondered how many of their clients figured out they could just copy/paste the report into wordpad...

      • A fucking calendar is a "Premium" feature. Yeah, that answer did fill me with a lot of hate as far as using Confluence.

        Well if it's so trivial and easy a feature then build a calendar widget yourself, Confluence supports writing your own plugins. Can't do it? Ok then pay somebody else to do it for you then. See what works out cheaper.

    • > Do companies buy software because they were browsing around?

      Yes. Managers or architects get impressed by an article or a demo and don't understand the limitations of a new toolkit. After such projects fail or get bogged down, my people get called to clean up the mess.

      • > Do companies buy software because they were browsing around?

        Yes. Managers or architects get impressed by an article or a demo and don't understand the limitations of a new toolkit. After such projects fail or get bogged down, my people get called to clean up the mess.

        Yes. But let's not leave the developers off the hook so easily. There is a lot of evangelism for developer's favorite tools, and many agitate for them. In the one field I'm involved in but don't have enough power, which is development of Emergency communications for Radio, there is so much evangelism and multiple approaches and parochialism that failure is pretty common, as people end up having to learn several processes, and non-computer types end up getting overwhelmed with whatever new fangled system som

  • by YetAnotherDrew ( 664604 ) on Sunday April 10, 2022 @12:01AM (#62433350)

    The mere fact that he frames this in terms of consumers shopping for things pisses me off. That tells me what he thinks of us. We're suckers to sell things to!

    The fact that he weren't aware/bright enough to frame this as the well-known "using constraints to unleash our creativity" tells me that they're not even aware enough to listen to. Um . . . to read.

    Matt Asay! Who cares what Matt's Ass says?

    • Meh. Incomplete edit: change from they to him. Fooey!
    • by Anonymous Coward

      Scanning this overlong cut-and-paste from a longread, I notice it is all about the tools you can buy. This guying is to reframe how "we" (really middle management) thinks about that. With as ultimate goal, "buy our stuff".

      Putting that frame aside for a moment, if "developer productivity is a must, not a nice to have", it's perhaps time to own up to having fucked that up in the workplace for political status game reasons. For verily:

      It's been noted that developers work best in silence for deep concentratio

      • by HiThere ( 15173 )

        What's best depends on what you're doing.
        OTOH, there needs to be limits put on that, or you (well, I) spend too much time trying this language or that to see what fits best. For what I'm currently doing I've settled on Python, but I only did that after trying C, C++ (with various toolkits), D, Java, etc. I'm finally back to Python, which is where I started. The deciding factor is it's a language that I can write on one OS and have it run (including database access) on another without recompiling. (Yeah

        • What's best depends on what you're doing. OTOH, there needs to be limits put on that, or you (well, I) spend too much time trying this language or that to see what fits best.

          We all will. There is a saying in the art world that creativity needs limitations. Programming is no different. Imagine a room full of programmers where any one had veto power over the language used for a project, and they were all evangelists for their favorite language.

      • by El Rey ( 61125 )

        Agree with the point that if you are wanting to improve developer productivity give them silence and offices with doors first like the research has proven out. There is over 100 years of research on human performance that is ignored by companies. Start there.

        I can see the point on restricting languages too as it can go too far into there always being some subset of the developer population in learning curve mode if you have too many. We recently did that and I think there are like 7 or 8 approved languages

    • The mere fact that he frames this in terms of consumers shopping for things pisses me off. That tells me what he thinks of us. We're suckers to sell things to!

      The fact that he weren't aware/bright enough to frame this as the well-known "using constraints to unleash our creativity" tells me that they're not even aware enough to listen to. Um . . . to read.

      Matt Asay! Who cares what Matt's Ass says?

      That's not the point, I'm certain.

      The point is, at some point, more choices becomes more of a problem than a help. The food aisle is just a good analogue for that.

      If you have ten tools to choose from to do the exact same task, and someone thinks adding ten more is a good idea, and now you have to learn those ten more tools, the tools end up becoming the task. Fragmentation, and pointless fragmentation.

      • That's not the point, I'm certain.

        The point is, like I said, "using constraints to unleash our creativity." But the author is too dim to realize we're creators, makers and not just shoppers.

        • That's not the point, I'm certain.

          The point is, like I said, "using constraints to unleash our creativity." But the author is too dim to realize we're creators, makers and not just shoppers.

          I guess I wrote that unclearly. He's missing the point, not you.

          Artists understand that creativity is directly tied to limitations. A bit more constrained perhaps than programmers, but if say, a photographer says, "I'm into bushes right now", it means they are using that constraint to end up framing and channelling a different look at those bushes. Not being a weirdo. A final picture is supposed to give a different look at bushes.

          In programming - which is still creating - having say dozens of ways t

  • by The Evil Atheist ( 2484676 ) on Sunday April 10, 2022 @12:17AM (#62433374)
    Fast, cheap, good.

    Choose two.
    • by Arethan ( 223197 )

      Amen

    • by ShanghaiBill ( 739463 ) on Sunday April 10, 2022 @01:48AM (#62433482)

      Fast, cheap, good.
      Choose two.

      That is accurate for many things in life, but not software.

      For software, quality is often negatively correlated with price.

      • Fast, cheap, good.
        Choose two.

        That is accurate for many things in life, but not software.

        For software, quality is often negatively correlated with price.

        The correct quote is "choose no more than two". You can certainly get all kinds of rubbish which is none of the above, or only one.

      • Fast, cheap, good. Choose two.

        That is accurate for many things in life, but not software.

        For software, quality is often negatively correlated with price.

        Another person who had to use Oracle?

    • by mveloso ( 325617 )

      You can get fast, cheap, and good if you have the right people.

      • You can get fast, cheap, and good if you have the right people.

        And how are you going to get (and keep) the right people? In most cases, the "right people" will quit if you don't pay them well - and if you do pay them well, it's no longer "cheap".

        • Re:No (Score:5, Insightful)

          by dvice ( 6309704 ) on Sunday April 10, 2022 @08:30AM (#62433800)

          > and if you do pay them well, it's no longer "cheap".

          I think that 10 good people with 10x salary make your project cheaper than 100 average people. Even if you exclude maintenance.

        • You can get fast, cheap, and good if you have the right people.

          And how are you going to get (and keep) the right people? In most cases, the "right people" will quit if you don't pay them well - and if you do pay them well, it's no longer "cheap".

          Exactly. All three is unsustainable. If your business is based on attempting all three, those low paid programmers you are abusing to get it out fast and good will end up leaving.

      • Fast, cheap, good, the right people.

        Choose two.
  • by Anonymous Coward

    Lets start with retail, the only reason less could be better is because the consumer can't gauge the difference. Product marketing has gotten very good at making even crap products look like premium. If the consumer is unhappy afterwards it's because they were fooled.
    Think I'm wrong, no one every said, too many choices at a restaurant. No one ever said they have too many different kinds of restaurants in their neighborhoods. No one ever complained that video rental stores have too many choices. No one

    • by sconeu ( 64226 )

      Think I'm wrong, no one every said, too many choices at a restaurant.

      That's actually the classic example of paralysis of choice. I've fallen for it too, with, "Do I want X? Oh, but Y sounds good! OOOH! Z!!! Shiny!!! Dammit, what do I want to eat!"

      • by dvice ( 6309704 )

        > Dammit, what do I want to eat!

        If you don't know what to do, you do what all nerds do in such a situation. Use math to solve it.

      • Think I'm wrong, no one every said, too many choices at a restaurant.

        That's actually the classic example of paralysis of choice. I've fallen for it too, with, "Do I want X? Oh, but Y sounds good! OOOH! Z!!! Shiny!!! Dammit, what do I want to eat!"

        AC might like a lot of choices, but too much choice in eateries can be a real problem. I've seen people freeze up at fast food restaurants, it seems to be a fear of making a "wrong" decision.

        Nothing like being stuck behind someone who can't decide on the product.

    • "[N]o one every said, too many choices at a restaurant."

      Actually, yes, they have. Frequently. Having too large a menu is considered one of the classic mistakes in running a restaurant. It greatly increases your costs while providing not nearly enough increased revenue to pay for it. In fact, in some cases, it can decrease your revenue, precisely because of the phenomenon under discussion here.

  • by oldgraybeard ( 2939809 ) on Sunday April 10, 2022 @01:28AM (#62433452)
    and the weak development tools, languages, environments, platforms and fads usually fade from the picture.
    • by SafeMode ( 11547 )

      you're a 6 digit though. basically a newb :)

      in regards to the story, i think restricting choice forces developers to either get creative to solution within the restrictions... or it forces inefficient use of time and subpar results when better options exist.

      really depends on the quality and choice of what you are limiting them to.

    • by HiThere ( 15173 )

      You seem to love the cloud. Well, for some applications, I suppose that's reasonable. But for many it's a really bad choice.

      • by Kwirl ( 877607 )
        I actually agree, however context matters. We run a small business, and the security and compliance offerings. also, managed certificates and platform updates are a very nice bonus. all things considered, its just a matter of time. Is it worth my time to manually go install platform updates, check certificates all the time, monitor logs, and all the other routine things. I'd absolutely love to have a large enough budget to include having dedicated people managing all of those things, and i could hav
  • Comment removed based on user account deletion
  • Short one: never.
    Long one: read the Art of computer programming.

    • by hrieke ( 126185 )

      Allow me to add my favorite book on programming, which sits on the shelf next to Mr. Knuth's opus.
      the dot, by Peter H. Reynolds. ISBN 0-7636-1961-2.

      If you fail to comprehend the lessons in Mr. Reynolds book, then perhaps programming isn't for you.

  • If you are a true professional, it won't matter to you if your employer uses technology X, Y or Z, or if you're restricted from using A, B or C. You'll have the capacity to adjust as required, because that is what professionals do. Being a professional also makes you accept that, in the end, it is not your project, and that you should have zero expectations regarding ownership, decision making or using the platform owned by someone else to experiment, and you understand that this kind of freedom and control

    • If you are a true professional, it won't matter to you if your employer uses technology X, Y or Z, or if you're restricted from using A, B or C. You'll have the capacity to adjust as required, because that is what professionals do. Being a professional also makes you accept that, in the end, it is not your project, and that you should have zero expectations regarding ownership, decision making or using the platform owned by someone else to experiment, and you understand that this kind of freedom and control is what you get on personal or dedicated research projects only.

      Before anyone starts calling me a names, I am a developer myself.

      This will rapidly devolve into a "No true Developer" argument though.

      A lot of developers in here. And Slashdot is about the worst "Ford versus Chevy" environment I've ever been in.

      Anyhow, if you have that ability to adjust and quickly learn whatever environment and programming you are thrust into, I'm impressed and that's good. But that might be the exception that proves the rule?

      • "I never make exceptions. An exception disproves the rule." - Sherlock Holmes, The Sign of Four

        • "I never make exceptions. An exception disproves the rule." - Sherlock Holmes, The Sign of Four

          Perhaps there are no rules then?

          But at least we must understand that if we have the greatest, most talented, exceptional, and flexible programmers determine the base level of competence and ability, there will in fact, be exactly 1 programmer in the world, all the others are doing something else then. I think that is the origin of the exception proves the rule chestnut.

  • by fbobraga ( 1612783 ) on Sunday April 10, 2022 @06:29AM (#62433706) Homepage
    Next question...
  • by Casandro ( 751346 ) on Sunday April 10, 2022 @06:40AM (#62433720)

    Code is just a by-product of the software development process, the real value is in the concepts and specifications that are created in it.

    This is something many people have understood in the last few decades. Good software design may be done rather efficiently with a set of tools, but it doesn't require those tools to be used. Instead good software design separates code from data and makes the code easily replaceable. In fact one common trope in C programs is to put the logic into constant data structures in your program and to only write a small program that will work on those structures with your data.

    However in some cases the problem of having to many choices can be bad. A good example are language constructs in programming languages. It's a good idea to write your software in a way an inexperienced programmer can read it. Any new language feature you use adds additional mental load on the mind of the person that needs to read it. For example in C avoid if's where there is just an integer in the condition clause. Avoid ++x and x++ operators, particularly when using the value. Avoid non-standard for loops. Put variable declarations where you first use them an _not_ on the start of your block, etc....
    It helps to limit yourself in order to make the resulting code easier to understand.

    • Code is far more important in practice. Code is the tangible thing.
      It is to an extent the very specification and concept you speak of, just done at a very low level.

      However, there is another big reason why 'code' should be thought of as the end product, and not just the by product. Software development is much more than just writing code.

      Programming languages have a lot of supporting tools. From IDEs, security scanners, build integration, packaging, monitoring tools... Build a new language, it will be years

      • "It is to an extent the very specification and concept you speak of, just done at a very low level."

        That's a wonderful little nugget of thought as it also means that there will be no bugs. Every "bug" will be part of your "low level" specification.

        I've worked at a company where my boss had exactly the same idea. This was at a VoIP company. The problem only start when you have to interfere with other people who don't see your code as specification, but instead things like RFCs or "common sense". With code wr

  • This means that that free box of doughnuts on Friday morning won't be the usual variety pack, but instead be all pink frosted. The one you hate

  • Has the author not heard of Technical Architects, who define the tools Dev use?
  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Sunday April 10, 2022 @11:58AM (#62434094)

    Of course they choice effect is rampant in IT, especially Web development. Every odd month there's a new fad. Ever since they ruby on rails hype (right here on slashdot, 14 years ago ... f*ck in getting old) and the VDOM craze started I've been actively working against the choice effect. I'm still using LAMP to this very day and can't wait until I see docker and node crowd go the way of rails. Bring comparatively conservative in my field has helped me keep my sanity and stay on top of things in PHP. Very helpful. I also see to it that my trainees stick to their PL of choice if it's not totally obscure or proprietary. One of them just started of with Python and is eager to get into JavaScript. I told him to chill and stick with Python for now. Python alone is a whole world unto itself, he'll have 10, years of things to discover there.

  • How many Microsoft engineers does it take to change a light bulb?

    The answer is zero because Microsoft only needs to declare Darkness to be The New Standard.

    ...an old Internet Exploder (IE) joke I admit, but it serves my point.

Always look over your shoulder because everyone is watching and plotting against you.

Working...