[{"data":1,"prerenderedAt":126},["Reactive",2],{"zV4EQzf3qQ":3,"_apollo:default":125},{"inspiration":4},{"id":5,"inspirationId":6,"commentCount":7,"date":8,"modified":9,"acf_inspiration":10,"__typename":114},"cG9zdDoxMTQ3",1147,null,"2022-11-30T08:11:55","2023-02-28 20:23:43",{"defaultColor":11,"accentColor":12,"tags":13,"technicalLevel":14,"layouts":15,"__typename":113},"#ed31c7","#4658dd","DX","lvl10",[16,23,34,37,44,49,56,59,61,68,75,78,84,91,93,99],{"desc":17,"title":18,"url":7,"image":19,"__typename":22},"A developer, software engineer, programmer, (however you like to call them) is usually a pretty unique person. As Alfred once said \"Some Men Just Want to Watch the World Burn\". \u003Cbr>Developers on the other hand want the world to run smoothly, seamlessly... like clockwork.","Top 6 things that demotivate a developer",{"mediaItemUrl":20,"__typename":21},"https://jalokim.graphics/api/wp-content/uploads/2022/11/n1.jpg","MediaItem","Inspiration_AcfInspiration_Layouts_HeaderBanner5050",{"desc":24,"title":25,"order":26,"images":27,"__typename":33},"I think comparing to a clockwork mechanism is on point. A developer wants to build small little springs, levers and gears. Set all of these components in a solid housing, apply some tender, love and mineral oil for things to move smoothly. And at the end of the day, the best part of it all, is when a dev can wind that single crown on the side of the clock and watch the entire mechanism come to life.\r\n\u003Cbr>\u003Cbr>\r\nEach piece moving in sync and unison with another, one gear passing information to another. That is the endgame, that feeling is what a coder expects after hard days, weeks or even months of work.\r\n\u003Cbr>\u003Cbr>\r\nOver the years of working with devs, being a dev, working with Product Owners and getting familiar with Product Owning I can tell that the business side and the programming side don't usually see eye to eye.","What drives a developer?","reversed",[28],{"image":29,"__typename":32},{"mediaItemUrl":30,"mimeType":31,"__typename":21},"https://jalokim.graphics/api/wp-content/uploads/2022/11/n2.jpg","image/jpeg","Inspiration_AcfInspiration_Layouts_FourBlock_images","Inspiration_AcfInspiration_Layouts_FourBlock",{"pattern":7,"title":35,"__typename":36},"So what kinds of tasks or processes demotivate developers? \u003Cbr> And how to avoid them","Inspiration_AcfInspiration_Layouts_Justquote",{"desc":38,"title":39,"order":26,"images":40,"__typename":33},"Imagine working on a wedding cake for at least a week. A large 3 layer cake. with icing and rose petals and handmade figures adorning the top. And minutes before the wedding you are asked to dispose of it. No-one saw it, no-one tasted it. Sure you got paid, but why do the work if it's going to be thrown away.\r\n\u003Cbr>\u003Cbr>\r\nUnused code is time spent planning, building, testing, while somewhere along the way the higher-ups decide to cancel the idea and never publish the code. This includes code that is used only for a while, as I call it temporary code. Things that are manually added then removed after a certain amount of time. Convert manual work to a manageable and automated version, devs love that.","#1 Redundancy",[41],{"image":42,"__typename":32},{"mediaItemUrl":43,"mimeType":31,"__typename":21},"https://jalokim.graphics/api/wp-content/uploads/2022/11/n4.jpg",{"desc":45,"title":46,"order":47,"__typename":48},"Most of the time temporary code is just a gimmick, an alteration of an existing functionality. Instead of asking a dev to make a new kind of modal, or a new kind of form, just use the existing ones you might already have. Especially if it's something temporary that will expire in a week? a month?\r\n\u003Cbr>\u003Cbr>\r\nThe moment a developer has to type in a start & end date of a feature in the actual code, you know you've gone too far. Automate this. Invest the time to make repetitive events or features manageable and have the content team activate or deactivate them when needed.\u003Cbr>\u003Cbr>\r\nThis excludes AB testing, that by nature is temporary code. That being said even AB tests should be prepared in an MVP (Minimum Viable Product) or in a \"fake it till you make it\" kind of way. You are proving a concept, don't build 2 fully functional versions as an AB test. Use the AB test results to build the final version of a feature.\r\n","Avoid temporary features with existing functionality","normal","Inspiration_AcfInspiration_Layouts_QuoteBox",{"desc":50,"title":51,"order":47,"images":52,"__typename":33},"Best case scenario is when everyone knows the end picture of the product and everyone has a clear path towards it. But in a real world that is almost never the case. CEO's, PO's, or even clients don't really know what they want and what will bring the most value. \u003Cbr>\u003Cbr>\r\nWay too often the development team is not involved in the long term roadmap or plans for the future. With a shortsighted backlog a developer doesn't know how to prepare for the end game.\u003Cbr>\u003Cbr>\r\nBad preparation can lead to redundant code or POCs (Proof of Concepts) that burn before seeing the light of day. See #1 Redundancy.\u003Cbr>\u003Cbr>\r\nYou'll soon see that most of these demotivators are closely related to each other and they intertwine. ","#2 Being in the Dark",[53],{"image":54,"__typename":32},{"mediaItemUrl":55,"mimeType":31,"__typename":21},"https://jalokim.graphics/api/wp-content/uploads/2022/11/n5.jpg",{"desc":57,"title":58,"order":47,"__typename":48},"A dev gets asked to build a laser that can cut through foil, but only the foil, not anything underneath it. So a developer starts to build it, but somewhere along the way the PO comes back and says we need a grabber too, so the vice can hold the item while the laser cuts the foil.\r\n\u003Cbr>\u003Cbr>\r\nA month later it turns out a huge machine was built that delicately holds a piece of candy while a laser cuts and extracts the contents from inside. If you told a dev you want to open a candy bar, he'd take it, grab the zigzagged part and just pull away the foil.\u003Cbr>\u003Cbr>\r\nThis is an exaggeration ofcourse but sometimes thats what requests without knowing where we're going look like.\u003Cbr>\u003Cbr> Involve the dev team, or a representative in roadmap discussions, plan short and long terms plans, have one solid and unified vision of the end game. You will save a lot of time, money and stress. Often there are easier solutions to a problem.","We need to build a laser that can cut through foil",{"pattern":7,"title":60,"__typename":36},"Spend more time planning, and being sure of what you want. Constant spec changes and \"slapped on\" features are not maintainable",{"desc":62,"title":63,"order":26,"images":64,"__typename":33},"Closely related with #1 and #2. Some tasks demotivate a developer because they sound wrong, or are badly thought out or are just redundant. In situations like these I bring out the good, old question machine. As a dev just start asking questions, like \"should this also be for logged out users\" or \"what happens if case B, or case C\". If you get answers and there is enough data supporting the feature, then maybe the goal was misunderstood.\u003Cbr>\u003Cbr>\r\nUsually though the answers are monosyllabic grunts of dismay which force the task giver to go back to the drawing board and figure out all the loose ends. Keep inline with your end game goals.","#3 Not enough thought",[65],{"image":66,"__typename":32},{"mediaItemUrl":67,"mimeType":31,"__typename":21},"https://jalokim.graphics/api/wp-content/uploads/2022/11/n6.jpg",{"desc":69,"title":70,"order":47,"images":71,"__typename":33},"Writing code is not like building a house, where you first see some foundations being poured, then walls being erected, followed by a roof and windows, doors. Often during development of an application there is background work that is being done. The end user or stakeholder doesn't see this and wrongly assumes someone is being lazy or not pulling their weight.\r\n\u003Cbr>\u003Cbr>\r\nThis is more about educating the stakeholders about how code development works. Not everything is done on the frontend, and not everything is always a tangible feature. Trust in your dev team and with proper scrum methodologies the higher-ups can always be up to date with current progress of features.","#4 Pressure over invisible progress",[72],{"image":73,"__typename":32},{"mediaItemUrl":74,"mimeType":31,"__typename":21},"https://jalokim.graphics/api/wp-content/uploads/2022/11/n7.jpg",{"desc":76,"title":77,"order":47,"__typename":48},"The next 2 are demotivators that popped up often in my polls. But they are more about house keeping. Chores that just have to be done even if it's not any fun. Even in a normal household taking out the trash or cleaning the bathroom is something most people would like to skip. But they still need to be done.","House keeping and plain old boring work",{"title":79,"desc":80,"image":81,"__typename":83},"#5 Bugs that can't be reproduced","Personally this one doesn't demotivate me but it is possible that getting an issue ticket that can't be reproduced sucks out your passion. Following the steps the tester used and not getting the same error is somewhat soothing (because it's not happening for everyone), but also frustrating (because you'll need to fix it some day). Knowing there is some kind of combination of actions that cause this can keep you up at night.\u003Cbr>\u003Cbr>\r\nMany times it's just bad luck, a network delay or interruption, some other process lagging on the end users device, or on the server, an outdated device or just plain user error.\u003Cbr>\u003Cbr>\r\nThere is no magic remede for this apart from more tests, QA testing, testing on older and slower devices or traditionally blame it on a fluke and hope there are no more issues of the same nature in the future.",{"mediaItemUrl":82,"mimeType":31,"__typename":21},"https://jalokim.graphics/api/wp-content/uploads/2022/11/n8.jpg","Inspiration_AcfInspiration_Layouts_PosterPreviewer",{"desc":85,"title":86,"order":47,"images":87,"__typename":33},"This is the definition of a chore. Code should be documented and described so that team members and new onboarders have an easier time getting to grips with all thats happening in a project. This has a lot of added value but is often overlooked or ignored either because no-one wants to do chores or #4, its invisible progress.\r\n\u003Cbr>\u003Cbr>\r\nAs boring as it can be, writing documentation is just something developers need to do. And higher-ups need to understand its value in the long term. Along with automated testing it's the easiest components of an application to exclude and save costs on.\r\n\u003Cbr>\u003Cbr>\r\nTry to share code documentation amongst the team, everyone should be pulling their weight and not have 1 person dedicated to going chores. Documentation can be done in small shifts to make the chore seem shorter and easier to do.","#6 Writing documentation",[88],{"image":89,"__typename":32},{"mediaItemUrl":90,"mimeType":31,"__typename":21},"https://jalokim.graphics/api/wp-content/uploads/2022/11/n9.jpg",{"pattern":7,"title":92,"__typename":36},"TLDR;",{"title":94,"desc":95,"image":96,"__typename":83},"Coding is not a production line","Your software, your developers and your entire organisation should be striving towards making an autonomous machine. IT is not a factory, it's not manual labour.  You wouldn't want a watch where you'd need to manually turn a gear every once a while for it to keep running?\r\n\u003Cbr>\u003Cbr>\r\nA happy dev is one that knows what the end game is, that is well informed and has time to figure out the best path towards a solution.\r\nA good dev can assist in decision making, and can also determine where cost optimisations can be made. A mature dev knows that even the boring tasks, the chores to do around the house are also part of the game and adapts to it, not complains and avoids doing it.\r\n\u003Cbr>\u003Cbr>\r\nLow hanging fruit and \"quick wins\" give immediate results but many times also bring tech debt. Give a little thought to the graph in this article.\r\n\u003Ci>\u003Csmall>Image courtousy of https://outfunnel.com/pipedrive-automations/\u003C/small>\u003C/i>",{"mediaItemUrl":97,"mimeType":98,"__typename":21},"https://jalokim.graphics/api/wp-content/uploads/2022/11/geeks-and-repetitive-tasks-02-1024x622-1.png","image/png",{"fieldGroupName":100,"suggestedPost":101,"__typename":100},"Inspiration_AcfInspiration_Layouts_NextPosts",[102,115],{"slug":103,"featuredImage":104,"title":108,"acf_inspiration":109,"__typename":114},"does-code-quality-even-matter",{"node":105,"__typename":107},{"mediaItemUrl":106,"__typename":21},"https://jalokim.graphics/api/wp-content/uploads/2023/02/leavess-500x500.png","NodeWithFeaturedImageToMediaItemConnectionEdge","Does code quality even matter?",{"accentColor":110,"defaultColor":111,"technicalLevel":112,"__typename":113},"#30f2eb","#ef26ba","lvl20","Inspiration_AcfInspiration","Inspiration",{"slug":116,"featuredImage":117,"title":120,"acf_inspiration":121,"__typename":114},"6-visualizations-to-improve",{"node":118,"__typename":107},{"mediaItemUrl":119,"__typename":21},"https://jalokim.graphics/api/wp-content/uploads/2023/02/uasgdaysdgaysfdaustfdat224w12-500x500.jpg","How to improve feat. easy to embrace pictograms",{"accentColor":122,"defaultColor":123,"technicalLevel":124,"__typename":113},"#ff3a6f","#ffac28","lvl1",{},1713287146401]