151–160 of 275 posts
They are either extremely untalented and take a whole Sprint to write a simple function,
Or are really smart and take a whole Sprint to write a simple function (because it must be perfect).
So you're in good company.
Also, the person that "just gets it done" can be king in some companies (agencies/consultancies/corp). Just learn to avoid critical security mistakes and you're golden.
Do not give up so early thinking on changing roles unless this is what you want to do. And notice that PM requieres a different set of skills. I even dare to say that the knolwedge gap could be bigger moving to a bigger company and in the way taking a new PM role. And learning PM without experiencing the role is even more difficult.
If I were you I will get a good book or on-line course and work on it on the side. Go to the sylabus of some good university course or some online course of the same sort and get some funcdamentals of computer science on algorithms and data structures. It might take you a number of months but you will enjoy and learn from the begining. The type of mistakes you say you did in that first role are pointing that you need some fundamentals.
I'd argue differently. Congrats for having the courage to recognize your problem. The analogy that comes to mind is I've been playing basketball in my local town, and now I've gotten promoted to play in the big city. I now feel like a small fish in a big pond. If you enjoy software engineering, I'd say, double down. Now that you're at the medium software company, seek mentorship and coaching from others. In addition,…
I don't think I've come across coursework that's intended to level up coding ability itself (i.e. good software engineering/design) rather than teaching basic knowledge things. I'm curious if anyone has come across anything of that nature.
Have you seen a shortage in people who dress up their preferences as facts? Maybe a better question is, who is producing the good software? Oh, and software ought to include malware (personal preference).
I can't comment on your domain complexity but this in itself helped me improve a lot.
Just try to understand what you are doing and why you are doing it. The idea that a problem should be 90% analysis and 10% execution has a lot of merit.
You could be suffering from impostor syndrome. This is the feeling that someone gets when they are in a role but feel like they aren't living up to it and don't belong there, even though they may not be doing anything wrong. I also have 10+ years in software development and have switched companies several times. Every place is very different in terms of how their architecture is set up and what's expected in a softwa…
I don't know what it is about "imposter syndrome" but it's clearly having a moment. People are quick to label things "imposter syndrome" these days. Imposter syndrome is feeling like you are an imposter or fraud even though, objectively, your job performance is adequate. If anything, the original poster is describing the opposite of imposter syndrome, because they cited specific objective criteria showing that their…
It is not clear if what original poster described is objective: I am guilty of writing such software myself in the past. I was given unrealistic timeframes to write good software - in no way did that make my performance "inadequate", that's just the trade-off chosen for me (I wonder if the author felt pressured to deliver quickly). The only difference is I didn't blame myself for the outcome; rather, I felt proud of being able to deliver something that works on short order.
Over a decade with a handful of different vendors I've worked with, I have had "are they seriously asking us this question? how could they possibly not know this?" conversations with internal tech people at least once a day.
There are people and teams everywhere who have been assigned projects over their head - many with more fancy titles than "senior software engineer". Often we as the vendor are literally writing or correcting code they've written in order to solve the problem. And we're able to do so with minimal context because the mistakes are so basic. Sad to admit - but the reason they often buy software is that they're lost and need help and have no where else to turn and there is this nice vendor who they can email stuff too and have it returned fixed bc they're trying to close some million $ deal.
So yeah, par for the course. I guess don't be so hard on yourself and just focus learning on the job (that's what everyone else is doing). Software sales or a sales engineer type role could be an easy transition as well if you just want out.
Good luck.
Obviously there is a whole other skill set that is required for a PM but those skills vary depending on the organization.
Earlier quoted context omitted.
I remember one from Java ~20 years ago: public final static string HTTP = "http"; public final static string COLON = ":"; public final static string SLASH = "/"; public final static string WWW = "www"; with code like string url = HTTP + COLON + SLASH + SLASH + WWW .... Ignore any Java issues - not used it much in ~15 years. Edit: I asked the developer who had written this what it was achieving and he said it was best…
Well, actually... it could be a good practice, if the values are used in multiple places.
Not even digging about if this is really not the case, I question the premise that you should be a senior software engineer after merely 10 years in the field. In tons of other area, this would certainly be considered a criteria for "seniority"...