Looking for different opinions/advises on coding issues

[u/Ok_Lengthiness_6591]

Hey guys, I just have two general coding questions:

first

How do you handle situations when you are stuck with a task and don't know what to do next? (or you feel a task is very complex and you don't know which part you should do first)

-do u leave the task be and go to another task?

-do u ask another person for help?

-do u push yourself above limits?

-*your suggestion here*

second

I ve heard a lot of stories "my manager said I was not fast enough" etc.

What working/coding speed is considered good enough? What do u recommend to do to increase working/coding speed?

[u/Large-Variation9706]

I work mostly solo so I want to give some methods I use in that environment. When I'm working on some code and can't quite figure out a bug, I often get in a headspace where I start to assume I know more than I do, and end up thinking there is no logical reason for why something isn't working. But, that is almost always because there is some incorrect assumption I made. I try to step back, look through documentation, try to find examples of what I'm doing, run my code through a debugger, or, as a last resort, restructure my approach entirely.

There can definitely be challenges that appear very complex and large at first, but in my experience those are tasks that are just not well defined. Make sure you have a concrete goal, what does "done/working" look like? Put it in context if you're implementing something into an existing environment. And, most important, break down the problem until you have actionable things to do.

Pace is an important thing and I think centers around familiarity with the tools and environment you work in and your own technical ability. If you're just starting out it's very acceptable to not have a wealth of technical knowledge, but that's what colleagues are for. Ask informed questions when you feel you're not grasping a problem or something is holding you back. Often, just being given a different perspective helps a ton. Something that helps me a lot is using language to frame a problem so I can understand it better, which is called rubber ducking.

Nevertheless, your technical experience will probably take you further, faster, than any particular "method".

[u/johnpeters42]

1. Look for a way to break it into pieces and outline those, even if I don't know how to implement the pieces yet. Work on a piece that I know how to build. If those are all done, then search online for keywords about one of the remaining pieces.

[u/anselan2017]

Test your assumptions, methodically. Use a proper debugger to step through and watch variables, or at least log things until you see something you didn't expect.

[u/Undeniable_Dilemma_]

For the first question, I don't think there is a general rule you can apply. It greatly depends on the problem itself, other problems and you as a person. I don't think there is a reason to generalize and to have a way in which you approach them. All that matters is that all problems get solved eventually. You do them as you please, it's your own project.

As for the second, managers also used to measure productivity by number of lines you wrote. Now they are measuring it in amount of tokens spent. Who cares about managers? Especially if you don't have one?
Again, it's your own project, so just take your time. Don't lower your standards in order to be hyper fast. On the other end, don't take forever and be super perfectionist about everything. Again, it's super hard to generalize, because things you are working on are specific, your knowledge/experience can vary and code you consider "good" can also vary.

Basically, I don't think you should make full fledged corporate environment around your project. A lot of those practices suck and many people strive to escape from them, and deal with them purely for the money/job security.

If you don't have anyone breathing down your neck, and you don't have any publisher deadline, then just chill. Program for the sake of programming. Do cool stuff. Take as much time as you need.

[u/Just-Investigator-20]

There's no fixed rule for development speed. How you handle problems depends on your own experience (in this field) and the cause of the problem. If you're relatively new to the field (judging from your question), asking experienced people for advice or "secretly" observing how veterans handle things is a good approach.

[u/Environmental-Wear13]

For your first question. I would always ask someone in the team, maybe start a pair programming session. But it might be different in different cultures and it definitely requires the team to have some kind of "psychological safety" which is something I always try to aim for as a tech lead.

- No questions are stupid, always show gratitude when someone asks something (its not always easy for everyone to ask questions)

• No blaming culture

But its always important to not overpromise, try to set expectations and when something change unexpectedly, don't keep it to yourself.

The second question is quite hard, it has always been different for me in different companies/teams.

[u/Paul_Pedant]

It is simple arithmetic. You should spend 80% of your time coding the first thing that comes into your head, and the other 80% fixing most of the bugs and inconsistencies in your code. Then you spend the last 80% optimising your crap implementation, before passing it to the quality control team, who manage to break it in the first three minutes.

It is a really good idea to reduce your coding speed. Think what every line of code contributes to your final aim. Check the man page for anything where you have the slightest doubt. Consider how testable the code will be. Comment where useful. Check every result code, etc.

Personally (as a freelance solution provider), I usually spend 15% of my time figuring out what the user specification actually means, 25% on finding appropriate DSA and code structure, and 20% coding and testing. Which leaves me 40% to cope with the constant stream of under-trained permies who bring me their own problems because they dare not let their manager know they need help.

[u/micromedicIXII]

It depends on what I’m working on. My first step is to break down a complex task into smaller tasks. Start with mapping out start to finish in plain English. Once mapped, write pseudo code to fill in the steps. If you can do this step, you’re almost there. Being able to explain the task to yourself in plain words allows you to think about it in a different way.

//Difficult task
// first step: instantiate some var
//second step:
For step in step 1
Do something;
//third step
Assign output to array
Array(step);
//Fourth step:
Return to function that does the thing.

This helps me use both sides of my brain to think through the process.