"Developing" mindset

T

taiwan740

TL;DR - when developing or writing code, is it normal or usual to feel dread and overwhelm ("I can't do this", "this is too complicated") at the start of the process, or is it a sign of actually not being cut out for it, or something else?

Long version

I've always been interested in computers and using and configuring various types of systems. The jobs and projects that I have really enjoyed have been surrounding trying to get systems up and running. That's spanned from corporate enterprise systems, any UNIX-like operating systems, to things like installing Steam on FreeBSD via the Linuxulator and then running Windows games within that via wine-proton, or even the Games Porting Toolkit that Apple now have (basically the same thing...) - I ain't no genius so I'm not going round bragging cos all that I did was that followed instructions and got something working, but what I'm saying is, that's what I enjoy. I think one might describe this as more the Infrastructure, or MIS side of computing, perhaps. Like a mechanic "fixing' a car by buying and replacing parts, as opposed to engineering and machining their own.

The problem is when it comes to my coding skills for work. I'm not writing kernel or driver code in C++ or anything like that (I can't even think about how difficult developing drivers is), it's web stack. Things like Microservices, Javascript and jQuery. I frequently get overwhelmed, and feel very out of my depth quite quickly when tasked to do something. I've been doing this for years, and, you know, I'm not setting the world alight with my 1337 skillz and making millions, but at the same time my employer is very happy with the work I'm doing, unbeknownst to them the internal hair-pulling that has occurred for an hour or two whilst a bit of work is being done.

I know methodologies like Microservices, and languages such as Javascript and jQuery have reputations for nightmares that people have developed using them, but it is what it is, and I don't want to be the mechanic that blames their tools, but my question is if this is a common response when it comes to writing code?
 
It's normal. There are fears, or low self esteem, and thoughts spiraling (like "I can't do this"; "I'm a noob"; "it will take months to learn this", and so on). There is also no immediate reward, except new knowledge, but no money, no fame). It's also not really super fun to read a 1.000+ page documentation on some industry standard. I think it helps if there is an encouraging community. :)
 
Even when you've been doing it for decades, you still get that feeling. My experience has been undefined requirements is a primary cause.
What do I do? Grab a white board or blank paper, markers/pencils/pens, stare at the blankness and think about inputs and outputs.
Draw a box for inputs on one edge, draw a box for outputs on the other edge. Now think about "how do I get to there from here?" and draw more boxes and arrows.
Eventually it becomes trivial.
How to do it depends a lot on the restrictions:
language, environment. Those often drive tools and libraries.
Also keep in mind complexity.
Complexity of the solution for the sake of complexity is bad. Hard to prove correctness. Things like Microservices add complexity and can be good or bad.
Appropriate level of complexity is good if it can be proved correct.
Keep It Simple Stupid (KISS) principle is valid for a lot of reasons.
 
It can be serious problem for people who are prone to anxiety. Once you start the programming project all the unforeseen complexity and general mess comes up. That can be painful, especially if you encounter unforeseen things that cross from being annoying to maybe not doable (for you). If you don't start the project the world is and stays OK. So don't start. Procrastinate. Until it is urgent and you don't have enough time anymore.
 
cracauer@ said:
It can be serious problem for people who are prone to anxiety. Once you start the programming project all the unforeseen complexity and general mess comes up. That can be painful, especially if you encounter unforeseen things that cross from being annoying to maybe not doable (for you). If you don't start the project the world is and stays OK. So don't start. Procrastinate. Until it is urgent and you don't have enough time anymore.
Click to expand...
I've been doing this more lately although I never used to, I have preferred to "front-load" my problems, but if I'm struggling on something, like not knowing how to debug jQuery for example, then having to do the daily stand-ups and state that I'm still working on something starts to bring an element of foreboding. Nobody has mentioned "why is this taking so long" or anything of that nature, but I did abandon a work item the other day because it was making me miserable (it hadn't been scheduled in and was something I pulled from backlog because I ran out of other stuff to do), and I was asked why I abandoned it, and I just said that I was starting to dread working on it, and they accepted that as an answer.

In reality, I know it's all fine, but I find the "journey" really, very unpleasant.

My last job (where I worked in an office) picked up and mentioned about the noticeable change of tone between when I worked on configuration/installation projects which I really enjoyed and did a good job on, to when I was asked to develop a feature within a system, which would take forever and I'd be pretty unhappy. There was a memorable incident when someone decided to complain about a bug with one of my features after 5pm on a Friday and said that they needed me to perform some time-critical task, when it turned out that the "time-critical" issue was that they were using the system to order a foot massager for themselves (company money...) and orange highlighters for the stationary cupboard. At this point, I saw them drive past my office window in their red Porsche convertible with the top-down, and that was the defining moment that I decided to resign and take six months off working. Quite funny, really.
 
"Daily standups" with whole teams are poison for some developers. Unfortunately psychological knowledge is rare in corporations and they let anxious people build up anxiety until productivity collapses.
 
Without reading everything, starting my comments from the bottom ...

"Daily standups"? I think they're good, as long as they're done right. Too often, they take the character of asking every team member about their progress, requesting a report. That's bad. It can indeed create that kind of anxiety. Instead, they should be an opportunity to 1.) reflect the overall goal of the whole team (do we see issues reaching it?), 2.) give everyone the opportunity to speak up, either because they need help with something, or because they ran out of work and want to know where they can support and 3.) identify topics that should be discussed in smaller groups. There should never be the expectation that everyone "reports something".

Then, about the initial question, I'd say this also diminishes with experience. Every meaningful programming project will look too large and too complex to manage at first. That's why you try to split it into small and manageable sub-problems, and solve them one by one. How you do this splitting best, and where you best start comes with experience. And with the experience of success, you will also grow confidence being able to solve "large" problems using that approach.
 
zirias@ said:
"Daily standups"? I think they're good, as long as they're done right.
Click to expand...
Done right to me implies as short as possible. I think the most useful items are "blocked by" or "stuck on". Don't solve it at the standup, but get with others after that can help you get unblocked or unstuck.

One phrase I've always hated about "agile" is "hold others responsible for not doing their job".
I've always answered:
"How do I hold a peer responsible? All I can do is publicly shame them in these meetings".
 
mer said:
Done right to me implies as short as possible. I think the most useful items are "blocked by" or "stuck on". Don't solve it at the standup, but get with others after that can help you get unblocked or unstuck.
Click to expand...
I'd say that's more or less another way to express what I meant above. The IMHO most important thing, it should never be an individual "status report".

mer said:
One phrase I've always hated about "agile" is "hold others responsible for not doing their job".
I've always answered:
"How do I hold a peer responsible? All I can do is publicly shame them in these meetings".
Click to expand...
I didn't read any literature here (not too interested), so I don't know exactly the context of this phrase. But could it be a misunderstanding? Because I think on a team level (as opposed to individual), this could actually make sense. You certainly should make it transparent when you're blocked on something because some other team currently doesn't do what you need. That way, product owners (or other responsibles) can be aware of that and get into discussions or negotiations about priorities.
 
zirias@ said:
That way, product owners (or other responsibles) can be aware of that and get into discussions or negotiations about priorities.
Click to expand...
That is the way is should work, sometimes it actually does but it highly depends on the team dynamics. In practice (at least for me) it usually winds up of a week of "I'm blocked by X not being done", the manager that should be setting priorities or getting the help so X gets done, doesn't do their job and it winds up feeling like public shaming. Imagine reporting for a week "I'm still blocked by Joe not completing his task. I've offered help but get no response, others have offered but get the same no response".

As for the phrase I used, it may not be in any of the literature, but it's been used by almost every scrum master I've worked with.
 
zirias@ said:
"Daily standups"? I think they're good, as long as they're done right. Too often, they take the character of asking every team member about their progress, requesting a report. That's bad. It can indeed create that kind of anxiety. Instead, they should be an opportunity to 1.) reflect the overall goal of the whole team (do we see issues reaching it?), 2.) give everyone the opportunity to speak up, either because they need help with something, or because they ran out of work and want to know where they can support and 3.) identify topics that should be discussed in smaller groups. There should never be the expectation that everyone "reports something".
Click to expand...

Well, there is another potential problem from such meetings: inflation.

Hearing what your coworkers got done can lead to an impression that you are not as effective, and then present your progress as more effective than it actually is. That's bad, because now you are the one that looks far ahead and gives some members of the team opportunity to be anxious and inflate on their own. Until you go full circle.
 
cracauer@ I'd say that's yet another reason why such a "daily standup" should never ever get the character of everyone giving their "status report". I fully agree that's contra-productive in many ways.
 
taiwan740 said:
I frequently get overwhelmed, and feel very out of my depth quite quickly when tasked to do something.
Click to expand...
It sounds like you're eager to understand how, why, and when each part of your infrastructure talk to eachother. I think once you appreciate this you won't be pulling out your hair so frequently.
 
zirias@ said:
cracauer@ I'd say that's yet another reason why such a "daily standup" should never ever get the character of everyone giving their "status report". I fully agree that's contra-productive in many ways.
Click to expand...
Yeah, those are a total waste of time, especially when they use the gantt chart or a spreadsheet to pressure someone to hurry up with their part of the project.
 
I had my first break down mid 2008. It was OK I had worked hard for it and was (retrospectively) a great learning process. So much so that the second one I had around 2015 was qujte uplifting (you tend to stop worrying about anything and everything or your head expoldes, least thats my personal experience). There is only one person in my development team, so a daily stand up could potentially waste hours and be a precurser to number 3.
Project started 2006 now on version 5 17 years later. The missus asking 249 times a day but when will you finish.
 
Alex Seitsinger said:
It sounds like you're eager to understand how, why, and when each part of your infrastructure talk to eachother. I think once you appreciate this you won't be pulling out your hair so frequently.
Click to expand...
I had been working on the same system for over a decade in my last job and I felt like it then, throughout that time, and continues now with new system.

It just feels very, very unnatural, like trying to throw with your opposite hand, except with practice it doesn't get any better.
 
This reminds me of the meeting with our software engineer. I was designing the hardware using the new 68k processor from Motorola.

He was thrilled to learn from me all the flexible, multiple registers he had access to in assembly and rattled off what he was going to use each one for.

Little did I know that he was asking me if he would have all those uses all at the same time, far more than the actual number of registers the CPU had and we didn't realize it till he was somewhat deep into the code.

The language barrier was part of the problem as he was Israeli.
 
George said:
It's normal. There are fears, or low self esteem, and thoughts spiraling (like "I can't do this"; "I'm a noob"; "it will take months to learn this", and so on). There is also no immediate reward, except new knowledge, but no money, no fame). It's also not really super fun to read a 1.000+ page documentation on some industry standard. I think it helps if there is an encouraging community. :)
Click to expand...
I think it's pretty common in this industry. Reminds me of this podcast about imposter syndrome:

Heavy Networking 672: Overcoming Your Imposter Syndrome - Packet Pushers

Lots of folks suffer from impostor syndrome. Tech is complex--how could you know what you’re doing? And yet, many of us are responsible for incredibly complex IT systems. Fake it ‘til you make it, right? To handle the cognitive dissonance of impostor syndrome, we overcompensate. In doing so, we...
packetpushers.net packetpushers.net
 
This thought pattern went into remission for a few months whilst I was put onto a different project, but now it's back.

What use is "loose-coupling" when the company has decided to trash the previous version and re-write it all again in a new tech stack? I have a strong suspicion it's all a bit of a gimmick.

Maybe I've been watching too many films like The Social Network and actually expect to be able to make something usable and worthwhile in a weekend. Although I have done that in the past to a certain extent, but it hasn't matched the "code conventions" inflicted on us, such as using switch expressions instead of 'if' statements, doesn't fit the mediator pattern, isn't built around the very-poorly-defined definition of "events" and all that nonsense, including unit and integration testing. That or perhaps I'm just a bad coder.
 
This is why I'm not a developer:

1710042835340.png


:)
 
A year later and another year of experience.

The answer is it isn't my problem. It's the commercial software industry area that I work in. It has an exclusive "drag it out" and "make it as complicated as possible" mentality that is severely having itself over. Fed up with being involved with projects that get pushed back months or even years due to slow development. And that's not the small stuff that is always there with every project that isn't yet implemented, it is critical, major features, because two years were spent implementing "<insert_basically_any_pattern_or_library>" when we didn't need to, and subsequently there's a load of issues with it because it hasn't been done properly and nobody understands or can debug it. Course there's no documentation, and you ask online on Reddit or what-have-you, they have the gall to say RTFM.

It is miserable. I have spoken to countless people about it now and it seems that around 2019-2020 people got all starry-eyed about the Kubernetes bandwagon, set off on some over-ambitious project to rewrite their otherwise-fine applications in "new-hot-stuff" land, and it's just spiralled out of control because they don't care about producing results, all they care about is adding patterns and libraries to their developer repertoire. What is the point in that? Companies don't exist just for developers to go on some "whim" for the challenge.

And you can't just protest either because it's such a prevalent sickness to the industry that you look at job adverts and they are asking for 10 year experience in VB6 and Kubernetes hosted on Mac OS (it makes no sense either, that's the point) for $15k a year in the City of Hell-on-Earth. You then apply with a CV exactly to what they request and they reject you anyway without an interview.

I may be on a bit of a rant but this is my experience. I'm tired of the industry and the lies it is distributing that these "modern" frameworks and libraries actually make any real world benefit, unless you have 1 billion requests a minute and you're harvesting the personal and private data of each of your users simultaneously, then and only then, do you perhaps need to consider implementing something like a distributed service environment, and you'll have large developer resources and documentation to support it. Not when you're making a website selling low volumes of widgets.

Bring on AI. I even copied one of our implementations into an AI model and it deduced that it was over-engineered. Brilliant.
 
You must log in or register to reply here.
Back
Top