This is an anonymous question sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are us...
For further actions, you may consider blocking this person and/or reporting abuse
Jumping into the code right away.
It's a strength when doing maintenance work. I usually feel pretty comfortable combing through other people's code.
But it's a big weakness when starting new projects. I often feel like I have no skills what-so-ever in planning a project in a meaningful way. I always throw things together and iterate until it works.
I mean, after over 10 years of working as a developer have an idea what reasonably good things are to throw together for a project, but besides that I'm often lost.
The reverse can also be true. Over-analyzing, perfectionism and fear of doing something wrong can be pretty paralyzing at times.
Yes.
I could certainly use some light-weight software project planning framework, haha
What else would you do? I mean code is the expression of a developer. You don't hear painters talking about how their main fault is jumping into painting right away. Or maybe they do? Perhaps they sketch a painting in pencil first? Now if you are developing a system for someone it is a good idea to do storyboards, rough mockups of how things will look, simply to communicate with the customer to ensure you have a common understanding. But there are reasons detailed up front design fails. youtube.com/watch?v=wCFKKDbfoVg
Often, I get the feeling, that if I go on, I will end up with a big ball of mud.
I am this comment
Forgetting to ask the "why" of a request, especially of features. Sometimes, the feature is actually a workaround for a bug that needs fixing.
Also, if you're in an industrial-manufacturing setting, always ask them to define in a flowchart what the heck they want, JEEEEEEEEZ (any other tips for this are welcomed sdjhfksdjhkdj)
100% agree. Asking why someone wants something is really important.
A lot of customers I've had find it hard to be precise and abstract at the same time. They'll say things like "and then Johnny sends the document to Maria" while they mean "and then the reviewer uses system X to send the document to the archivist" or something. A flowchart can help but it's usually too much to ask (or seen as your job).
Yes, it's pretty nice how so much divination work can easily be cut out just by asking why someone wants something!
In my case since I work in an industrial setting, I need to know what context of the changes they want on a machine. I found myself finishing a feature only to be told that it's not operationally allowed, so, from now on if they want a change in process, I need to see a flowchart with the change. If it's just small changes then I can do those without a flowchart, but major features that affect how a machine is operated? you better give me a flowchart 😂
Tried this yet? Alistair Cockburn: Basic Use Case Template (1996)
If anything, it gets across the multitude of decisions that have to be made.
aaah that's a great template! I've used some that are similar, but recently I found myself finishing a feature with use cases that were approved, but on testing we find out it's not operationally allowed! Which is why I'm now asking for flowcharts for almost everything 🙈
Thank you so much for sharing!
Without a concrete example it sounds like the existing system is too inflexible to satisfy the actual needs (i.e. approved use cases) of the user-base.
So while the flowcharts may prevent "wasting effort" they're just covering symptoms that are going to get worse as time goes on.
Also sometimes it's necessary to gather user stories to understand the needs better. Regardless of where these tactics may have originated from or where they are currently being used, it can be at times useful to "cherry pick" approaches without buying the whole farm.
self doubt.
Lazy to read. Often there's an answer I need but I'm too lazy to read the whole article so I just spend much more time just clicking a ton of links looking for code blocks.
me too - I'm looking for just some examples.
Tarpitting myself with all the side-shoots that could have waited until later.. but then I have always enjoyed the journey more than 'being done', so it's natural to extend the journey 😁
Perhaps I should give myself a new title of 'Professional Yak Shaver'?
I work too fast. I often rush the end of projects because I am bored or tired. This leads to many silly mistakes creeping in.
I have had to learn to slow down and stop to think more and type less. I now also make myself wait an hour or two before submitting work for review and then reading through the PR with fresh eyes.
Sometimes though the speed is useful when I need to get a project out asap. But mostly it means I end up redoing work that I rushed.
I lack a lot of basic CS knowledge.
I mean, it's not all that bad. I don't usually spend a lot of time thinking about stuff like memory management. But especially when using 3rd party algorithm libraries or plan for large-scale databases, a lot of people who studied this stuff are way better equipped than I am.
E.g. I never paid a lot of attention to JS garbage collection till I started learning Rust. I mean, why aren't we funding this?
Web frontends.
I have zero talent with designing anything web. The layout. The tools. The scripting to make it all happen. I've no vision for the task so I stick to the backend where things make sense to me.
As a software developer, my biggest weakness is that I will feel nervous when I have some different project on my hand. To be specifi, I have presure when i need to manage many projects at the same time.
One I'm currently aware of is project planning. I always seem to struggle with it, maybe because I've never really done it in a professional setting but the moment I start I get confused and start asking myself questions like "Do I need to break this down further?", "Is there something I'm missing here?" and before I know it I get into analysis paralysis and I scrap the plan all-together and jump into code which eventually cripples me.
Meetings - especially remote ones where there is no one waiting to turf you out of a physical room. In this profession they descend into argument or generic chit chat and always overrun. Best meetings I attended were ran by exmilitary - arrival at start time was being late and there was no divergence allowed unless on topic, and they never overran
It helps to have someone facilitating the meeting (they can be a participant or not) that is super strict about keeping things on schedule. And an agenda to stick to.
Also a gentle reminder to the participants that you are all busy and have other work to do and if they can take their discussion offline that would be great.
Writing secure code. I enjoy building the project, not making it secure. Of course, there are some really easy things you can do (like CORS), but when building APIs for websites, I always forget to require Authorisation on the endpoints.
I guess it is my commitment to delivery and quality. Sometimes it gets in the way of my hobbies. Sure, it is great for my employers who are universally ecstatic with my productivity, but finding balance is hard.
This may be my weakness in general not only as a developer, that, I try to learn multiple things at a time.
Being horrible at politics. After years and years of logical exercises, corporate fuss annoys the heck out of me, yet unfortunately I can't Python Zen myself out of it.
Trying to learn everything, it's like jack of all trades but master of none. I tend to forget things when switching from one field to another (web dev to smart contract etc).
Can't kiss the BOSS's ass.