DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for Six Things You Thought Senior Devs Did (But We Don't)
Jason C. McDonald
Jason C. McDonald

Posted on • Updated on

Six Things You Thought Senior Devs Did (But We Don't)

If you're a junior or mid-level developer, you may have certain ideas about what constitutes a Senior Developer. There's almost certainly an idealized picture in your mind, and if so, I can safely bet you keep comparing yourself to that fictional ideal.

But what is a Senior Developer, really?

It doesn't help matters that practically every company has its own definition. In general, a Senior Developer is simply someone who has enough experience with software development to:

  1. Independently understand a given problem that needs to be solved in their particular knowledge domain,
  2. Enumerate one or more viable solutions and their merits, and then
  3. Implement one of the better solutions, likely as a member of a team, using the idiomatic patterns of the language and framework being employed.

Seriously. That's it.

So what about all those other things you've always imagined were true of Senior Developers?

1: We Don't Avoid "If" Statements

A lot of junior developers seem to be under the impression that conditional statements are only for wimps and n00bs. Nothing could be further from the truth!

Often the best solution to a problem is also the simplest. While there are times and situations wherein there's a better solution that a conditional statement or a loop, senior developers still default to the classics. As Donald Knuth famously said...

Premature optimization is the root of all evil.

The basics are the basics because they work. Don't go looking for a clever alternative solution to an already well-solved problem.

2: We Aren't Developing Algorithms

For the most part, it's the propeller heads at the universities who are coming up with better sorting and pathfinding algorithms, and more power to 'em!

A senior developer knows when to rely on the preexisting work of others who have come before. In other words...

Good programmers know what to write. Great ones know what to rewrite (and reuse).

Don't be afraid to use existing libraries, algorithms, and abstractions.

3: We Don't Customize Our Kernels

Seriously, we don't have time to be mucking about in the internals of our day-to-day operating system. A senior developer prefers to do the minimum necessary work to get a working environment that meets her needs...and then she leaves it alone!

Most of the time, the only reason a senior developer will be recompiling their kernel is to solve a hardware issue, and even then, it's compiled from an unmodified source. The only real exception is the folks for whom kernel hacking is a hobby...and that has nothing to do with seniority.

Beware yak shaving! If it ain't broke, don't fix it.

4: We Don't Have Regex Memorized Either

Your average senior developer is going to have one of her ten thousand browser tabs open to regex101.com too. Regex is infamously esoteric, and we have more important things to remember.

On a related note, if a typical senior developer is able to get the syntax for the tar command on Unix right on the first try without checking the docs, he probably has it tattooed on his arm.

Don't be ashamed to read the documentation, even if it's something you've looked up before.

5: We Don't Know All Top 10 Hottest Languages

Pick any random senior developer, and chances are that they know one or two languages very well, and have working proficiency in two or three others. They almost certainly won't have mastered a dozen different languages!

This is on purpose. A good senior developer is mostly interested in gaining further mastery of their primary languages, frameworks, and knowledge domains. It's impossible to know everything there is to know for any one language!

You don't need to learn everything. When you find a language you love, dig deeper.

6: We Don't Feel Like Senior Developers Either

No, really. We don't. As soon as you crest one mountain, you discover a dozen higher peaks on the horizon. We also have imposter syndrome. I've talked to 30-year-veteran software developers who still felt like they were faking it.

Software development is a life-long adventure. The destination is always changing; the journey is the interesting part.

Top comments (58)

Collapse
val_baca profile image
Valentin Baca • Edited on

My takes and comments.

1: We Don't Avoid "If" Statements

Absolutely. Senior devs consider readability as part of maintenance and it's important.

2: We Aren't Developing Algorithms

Agreed. We may be aware of more and apply them as needed, but consider how long it took to have a bug-free implementation of sorting functions.

I've never even needed to write a sort function in my actual job (despite it being popular in interviews). I've worked with Map routing and still didn't touch Dijkstra's algorithm.

The most advanced one I've used is Lamport clocks and that was reviewed with several other engineers.

3: We Don't Customize Our Kernels

I messed around with lots of Linux distros (distro hopping!) in college but now I just use macOS plus whatever Linux the company uses. But I've never touched the kernel.

4: We Don't Have Regex Memorized Either

HAHA so true. I may have a couple like "\w*" or "[a-zA-Z0-9-]" semi-memorized because they come up a lot but you can guarantee that I go to the Pattern javadoc Every Single Time because they're so easy to get wrong.

It's like double-digit multiplication. I could do it in my head, and try to, but I'll always verify and would expect others to do the same.

Protip: use the POSIX character classes! "\p{Alnum}" They're self-documenting

5: We Don't Know All Top 10 Hottest Languages

Looking at the top 10 according to TIOBE, Here's my personal grade on how well I know them, A-B are my primary languages, C-D are ones I occasionally work with, Fs are ones I don't know.

  • C: Grade D
  • Python: C
  • Java: A+
  • C++: D
  • C#: F
  • Visual Basic: F-
  • JavaScript: B
  • Assembly language: F-
  • PHP: F-
  • SQL: D

I consider myself a polyglot as my work has me looking at a lot of languages on a weekly basis. This morning I looked at Rust and Ruby. I don't know Rust but was perusing to help suggest features.

That said, remember that languages are tools; not religions.

If you "only" know "just" one or two, that's totally fine and great! Focus on them. Don't feel the need to learn 20 languages or even 3 if the ones you know fit your needs and allow you to build what you need to.

"Dance with the one that brought you." Master and build with the language you know. I can almost promise that the programming language you know is sufficient to build what you need and there's a company needs someone who knows it.

6: We Don't Feel Like Senior Developers Either

I wish getting the title of Senior Engineer was like the Sailor Moon or Power Ranger's transformation sequence where we suddenly got awesome powers and outfits and confidence, but that doesn't happen.

We're just more aware of the gigantic world of software that we don't understand. We're more aware that there will always be someone way, way smarter. We still google "array to list java" and "javascript import syntax." But we know a little more each day than we did before. Rinse. Repeat.

Never stop exploring and learning. It's a big world but you also don't need to do it all or know it all.

Collapse
jmccabe profile image
John McCabe

Re #5 - primary reason is C++ regex /= Emacs Lisp regex /= grep regex /= Java regex /= Python regex. That may be a slight generalisation (i.e. some of those may be equal), but my point is that regex isn't standard and, other than some of the dead obvious ones like those you mentioned, it's worth checking :-)

Collapse
mastacheata profile image
Mastacheata

I'm actually kind of a RegEx-Guru in our team. I love to fiddle with RegEx, but I only really know PCRE-Regex as I worked with PHP for most of my career and private projects. Now that my current job uses JS and Python all that knowledge is useless and I have to look everything but the most basic RegEx up in order to make sure they'll actually match what I intended.

Collapse
val_baca profile image
Valentin Baca

You're absolutely right! It's a whole mess out there. My point was even when I'm fairly confident in a regex, I'll always have the documentation up while I'm writing and verify it.

Thread Thread
jmccabe profile image
John McCabe

As an aside, I noticed your comment on Rust; what did you think of it? I've looked at it a couple of times and, every time I do, I think "what on earth were they thinking!". Why is that so many people can't just contribute to existing languages, rather than re-inventing the wheel in a weird way?! I look at so many 'new' languages and see these features that I used 30+ years ago in Ada!

Thread Thread
val_baca profile image
Valentin Baca

Sorry, this turned into a bit of a rambling rant. I might make a post about languages in general! haha

For me, Rust falls below the line for languages I want in my toolbox. That's not to say I think it's bad, it just doesn't fit the problems I'm working on. The reason I was looking at it was because I wanted to improve a particular command-line tool that I was using and wanted to get a sense of whether it would be too difficult to do or not.

It's perfectly valid to feel overwhelmed with the # of languages floating around and feel like we'd be better off consolidating rather than repeating.

When I look at a language like C++ or Python, it's clear to see the harm that piling on features to an existing language can do.

I will say that the Rust community is one that really loves their language in a way that I don't see that often and the language does seem to excel at the promise of extreme speed with safety and efficiency.

There's a ton of factors that go into language popularity: corporate backing, ease of use, fitting a niche but not being too narrow. Then, popularity becomes a positive feedback loop because the more popular a language is the more libraries and integrations are written for it, which increases popularity etc. We saw this with how Ruby blew up with Rails and Python with numpy, TensorFlow, etc. Java was the behemoth it was/is because of Sun/Oracle, while capitalizing on the promises of the JVM (which were met IMO) and filling the corporate server niche. That led to it being the language of choice for Android, which made it even more relevant, etc. etc. etc.

But a lot of what the languages give was all discovered decades before with Lisp. So why didn't it just take over the world? Well that's a whole other post.

In summary, from what I can tell, the Rust languages is evolving fast, has a community that loves it, and is filling a niche for systems programmers who want speed and safety.

I imagine you feel towards Ada-and-Rust as I feel a bit toward Java-and-Go. I picked up Go to learn it and found it not really doing much different than Java. Go's getting Generics; Java had that a decade ago.

That said, I really did find that Go just got out of my way and let me code what I need to.

It's also totally reasonable to always have a "hype buffer." It's okay to watch if something will stick around. If it's going to stick around then it'll still be there! If not then maybe you missed being on the first hype-train, but you can't get on every one.

Thread Thread
jmccabe profile image
John McCabe

FWIW - generics; not that I know much about Go's, nothing at all, but generics were in Ada when it was released to the public in 1983. I think it's fair to say there's nothing new in languages, just different, but different for the sake of being different doesn't cut it for me. :-)

Thread Thread
codemouse92 profile image
Jason C. McDonald Author

When I look at a language...Python, it's clear to see the harm that piling on features to an existing language can do.

I dunno, Python is my primary language, and I do not see this at all. I, like most of my fellow Pythonistas, love Python with all the passion Rust coders love their language with. I think it's an opinion thing.

Thread Thread
jmccabe profile image
John McCabe • Edited on

I'm not a big fan of python (nor any language where a slice/range written as 2:5 gives you elements 2, 3 and 4, but NOT 5), but I use it quite a lot for quick and dirty scripting. As far as I can tell, it took the best part of 10 years for Python 3 to overtake Python 2 in usage, almost solely as a result of a rash decision to make 3 substantially incompatible at the source level. I think that did Python a lot of harm. Contrast that to the Ada 83 - > 95 update, whose goal was to provide new features while keeping incompatibilities to a minimum (archive.adaic.com/intro/tech/8395c...).

In my opinion, this highlights how many language authors (I hesitate to call them designers) chuck something out there prematurely with the hit, in terms of language churn, being taken by the users.

Java, in its early days, was a prime example whereby a ton of breaking changes were made on every new revision. Sadly, following a few years of relative stability, Java sounds like it's reverting (admittedly based on what I've read, as opposed to using it) and C++ is getting out of hand with numerous half-baked features going in, with disappointing implementations, and the promise of more 'improvements' in the next revision, 3 years down the line.

Two things I'd been looking forward to in 'modern C++' were enum class and std::array, my hope being that, somehow, they'd manage to implement something almost matching the power and expressiveness of Ada arrays from 35 years earlier. Sadly, no. std::array is pretty much a wrapper round a C array, is almost impossible to create without a constant size, and still uses zero-based indexing at the source code level. enum class doesn't even match Java's enum in usefulness.

In addition to that, I watched part of a video where Herb Sutter was talking about potentially introducing 'interfaces' and asked a couple of audience members what they thought the default visibility of the methods and attributes in the example he showed them would be. When he went on to ask if they thought it would be a good idea if methods were public, by default, and attributes private, they agreed! You have a language that already confuses some people by having two composite type mechanisms, class and struct, with different default visibility of ALL members, and now you want to introduce a 3rd, abstract one, with different visibility depending on whether it's a method or an attribute? They must be out of their tiny minds.

As far as I can see, the people involved in the C++ revisions appear to have lost sight of the fact that bigger and bigger software systems don't need more and more complicated and confusing features and syntax; they need more clarity, simplicity and expressiveness as you can't expect all the people working on these systems to know a language as excessive as C++ inside out.

Sorry - went off track there. Python, yeah, I tend to believe Python is kind of in that mostly stable period; whether it will follow Java and C++ back to instability remains to be seen.

Thread Thread
val_baca profile image
Valentin Baca • Edited on

I have to strongly disagree on how slices are handled. It's standard for the range to be [x,y), i.e. inclusive of the first index x and exclusive of the second index y. It gives you a consistent # of elements equal to (y-x). So (3,5) should give 2 elements (5-3) starting at 3.

Standard as in used across many languages (links to single examples from each): C++, Java, Javascript, Go

It's as ingrained as the standard for-loop: for (int i = 0; i < n; i++) which is effectively [0,n)

Slices aren't ranges. I see that Ada uses ranges, but they're distinct from ranges.

I also have to disagree that Java is unstable b/c it has features added with new features. I've done a lot of Java migrations, but they're relatively minor. Very few deprecations are breaking and for the most part you can take old code and just run it on the latest JVM.

Thread Thread
val_baca profile image
Valentin Baca

I was more referring to GvR leaving the language as leader: mail.python.org/pipermail/python-c...

I'll admit that a majority of my interaction with python has been migrating some ancient (5 years old) scripts from Python 2 to 3 and the experience was not pleasant.

Thread Thread
jmccabe profile image
John McCabe • Edited on

I'm happy to bow to your superior knowledge of recent Java changes.

As for ranges etc, please check out the use of the range keyword and 'Range attribute in Ada. An array slice in Ada is a subsection of the array defined by a range.

Your suggestion of there being a 'standard' definition of a range in programming appears to be using references to languages that didn't exist when Ada had been using array slices and the range keyword and attribute for a number of years. Also, the suggestion of a 'standard' for loop makes no sense. The specific example you give is common to C, C++ and Java, at least, where array indices have not been abstracted away from machine representations. Even if you go back before Ada became an international standard, in 1983, it had introduced superior array handling that didn't rely on users managing (often badly) the mapping of array indices from the problem domain to the machine domain.

Thread Thread
codemouse92 profile image
Jason C. McDonald Author • Edited on

Most of us in the Python world see the transition from GvR's BDFL tenure, as good as he was, to the formal Steering Committee as a good thing. It's certainly brought a lot of improvements to the language, its internal development processes, and the community as a whole.

(Mind you, GvR is still very much involved, just with a layer of removedness that frees him up to pursue new ideas in Python w/ Microsoft funding.)

Python 3 was weird by nature of improving on some mighty weird things in Python 2, that lead to some things needing to be broken. That's why Python 2 wasn't deprecated until Python 3 was on full feature parity.

Thread Thread
val_baca profile image
Valentin Baca

That's good to hear. Thanks for your perspective!

Thread Thread
jmccabe profile image
John McCabe • Edited on

Sorry for the late reply (and possibly in a weird place; I'm not sure Dev's threading implementation is as optimal as it could be) but I've only just found out that Ruby, see ruby-doc.org/core-2.5.1/Range.html, treats a 'range' as Ada does; inclusively, if you use the simple s..e format. An extra dot is required if you want to use the exclusive (i.e. not including the end index) version, s...e. In addition, if you use ::new to create a range, you need to explicitly specify the 3rd, 'exclude_end', parameter if you want the non-default, exclusive, behaviour.

Collapse
iamwoodruff profile image
Dr. John Woodruff

Interesting point about POSIX RegEx syntax. I hadn't thought of it in that way. You might have persuaded me to use its classes more often. (But alas, only widely deployed in Java--especially useful in Android--but def not Perl). But for real, neatest RegEx tool is branch reset capture groups. For real, play with it! [RedirectMatch 307 (?i)^/(?|(p)rofile|(c)on..ct)\W(\S+) /$1/$2]

And was your "F" rating of C# a subconscious slip? (As in F**** Microsoft's basterized C)?

Collapse
val_baca profile image
Valentin Baca

Haha I actually have a lot of respect for C# as a language, but I've personally not written in it.

The grades were my own personal proficiency in the top languages. They're grades I gave myself; not the language itself.

Collapse
dominuskelvin profile image
Kelvin Omereshone

Very much spot on. Definitely learning a thing or two. Thanks for sharing

Collapse
aeiche profile image
Aaron Eiche

My current title is the lofty "Lead Software Engineer" and I can say that these items all apply to me as well, especially that last one. To me, the difference between the Junior and Senior engineers is almost exclusively non-technical in nature. There are a few practices that make a difference in terms of performance, and reducing errors, but for the most part Senior-developership is matter of leading, encouraging, and supporting. It's all the meta-work around software development.

Collapse
maciekgrzybek profile image
Maciek Grzybek

Totally agree, soft skills play massive role in a senior role. The ability to communicate and inspire. BTW awesome article :)

Collapse
leob profile image
leob • Edited on

And experience ... the ability to draw upon one's experience and thus to avoid making (major) mistakes, or going off in a wrong direction, that's huge as well, in my opinion :)

Collapse
ldrscke profile image
Christian Ledermann

WE DO google and use StackOverflow ;-)

Collapse
jmccabe profile image
John McCabe

Partly because we have such broad experience (and have seen so many new languages with bits that look like old languages, especially C) that we can rarely be sure the syntax we're using is what we really mean :-)

E.g. "if (x && y)" in C++/C means something different to the same syntax in Java, as does "if (x & y)" etc!

Collapse
maureento8888 profile image
Maureen T'O

This is a genuinely great post on senior devs! Really clarified the cloud of mystery surrounding what senior devs do that aren’t just β€œknow the framework best” or β€œpunch out a algorithm in X time”. Goes to show that senior devs are just as human. Thanks for this post! β˜ΊοΈπŸ™πŸΌ

Collapse
klvenky profile image
Venkatesh KL • Edited on

If there's a post that truly defines a senior guy this is it. I'd like to add another point though.
if a junior thinks that seniors are ridiculously fast at a problem then the simple reasoning behind it is that they've done it/something very similar before & did it facing lot of challenges which the junior will face if they go the same path. So the senior just tried to stop them from going all that way.
I've found it to be true many times on my way to be a senior(probably) & I ensure to say that to my team always. I'll say "I'm not super-fast not highly intellectual. It's just that I've thought of/solved this problem before"

Collapse
codemouse92 profile image
Jason C. McDonald Author

Absolutely! Good addition.

Or as I like to say, "Speed is a side effect of proficiency, nothing more."

Collapse
anshsaini profile image
Ansh Saini

So true

Collapse
ullissippo profile image
ullissippo

I'm a 37-year-veteran, and all 6 apply to me :). Started with COBOL (yes, that) and now that I'm approaching my retirement, PYTHON is my love.

Collapse
codemouse92 profile image
Jason C. McDonald Author • Edited on

Man, I would love to chat over virtual coffee sometimes.

Collapse
ullissippo profile image
ullissippo

:D Whenever you want, outside European Central Time working hours. Oh, and weekends also, I have to keep a healthful family life :)

Collapse
antonfrattaroli profile image
Anton Frattaroli

1: We Don't Avoid "If" Statements
No, but I avoid else statements. They add needless cyclomatic complexity.

2: We Aren't Developing Algorithms
I mean technically all the custom code you write is an algorithm. But hopefully you're never writing from scratch a well known algorithm that certainly has a battle tested package available for it.

3: We Don't Customize Our Kernels
I've used windows since switching from amiga in 1990. It gets the job done.

4: We Don't Have Regex Memorized Either
I know a lot of regex, but I'm not going to write an email regex from scratch for the same reason I'm not implementing a sorting algorithm.

5: We Don't Know All Top 10 Hottest Languages
I'd argue against using more than is necessary to keep the skillset required to run your company lean. Or else you're stuck with needing to hire a Java+Go or a C#+Rust developer.

6: We Don't Feel Like Senior Developers Either
I'm not sure how you can't. You sit through interviews, and when you're done you need to be able to say "this person is a [junior/midlevel/senior]". You can still be "on the junior side of a senior developer", I don't understand how it'd be unclear.

Collapse
thephydaux profile image
Chris Kent

You can't really "avoid" else statements though, if they are not explicitly there then it is still an implicit else.

Collapse
antonfrattaroli profile image
Anton Frattaroli

However it's worded, it works. This article gives a good example: axelerant.com/resources/team-blog/...

//Cyclomatic Complexity = 3. Npath Complexity = 4.
public int function (a, b) {
  If (a>b) {
    $return_value = a;
  } else {
    $return_value =b;
  }
  return $return_value;
}

// Above code can be rewritten as below.

//Cyclomatic Complexity = 2. Npath Complexity = 2.
public in function (a,b) {
  if(a >b) {
    return a;
  }
  return b;
}
Enter fullscreen mode Exit fullscreen mode
Thread Thread
codemouse92 profile image
Jason C. McDonald Author

Precisely.

The only time you might need an explicit else in my experience is when one or more conditions do not contain logic to leave the context (e.g. a return, break, or continue), and you have a block of code which should only be executed if none of the conditions were met.

Collapse
codemouse92 profile image
Jason C. McDonald Author

I think he means explicit else. I mostly agree it adds unnecessary complexity, although there are exceptions.

Collapse
pinotattari profile image
Riccardo Bernardini • Edited on

About regexp: I see that I am among the few that actually like them. πŸ˜„

I learned them quite early, even before university. I was born, in a CS sense, in the 80's with Sinclair, Commodore, and stuff. I always had a fascination for compilers, so I bought Compiler construction for digital computers by D. Gries and I learned about grammars, parsers and, yes, regular languages.

I find regexp a very powerful tool, although I agree that the most complex ones look some transmission error... In my free time every now and then I tried to come out with a different way to write regexp.

The GNAT implementation of Ada provides the SPITBOL alternative to regexp; I am still unsure if it can be easier than regexp

About tar: xkcd.com/1168/ πŸ˜†

Collapse
renanlazarotto profile image
Renan Lazarotto • Edited on

1, 2 and 4 are so true even if I'm not a senior yet (I'm in a position that sits in between junior and senior, which I believe its called 'mid level' in english).

I usually spend some time on 1, but a lot of time on 2... I love to go 'libhunting' :D

Collapse
raissamartinsmenezes profile image
Raissa Martins

great points :) i was explaining this to a junior dev yesterday. it doesn’t matter your seniority we are always learning and sharing with each other every day <o/ can i translate you article to portuguese to reach our community in brazil?

Collapse
codemouse92 profile image
Jason C. McDonald Author • Edited on

Absolutely! Just as long as you link back to the original and credit me as the original author. :)

Collapse
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄

Thank you for this.
Number six is especially spot on!

Collapse
gmeben profile image
Grant Eben

Yeah, number six hits hard.

Collapse
sarahob profile image
Sarah πŸ¦„

β€œSoftware development is a life-long adventure. The destination is always changing; the journey is the interesting part.”
This β˜πŸ»πŸ’―

Collapse
recitomartins profile image
Martins Gouveia

Article to be beside the bed for consultation.

Collapse
leob profile image
leob

Brilliant :) good to put some of these myths to rest

Collapse
phongduong profile image
Phong Duong

No matter what seniority you have, you will always have to keep learning. Thank you for sharing

Collapse
dattvidc profile image
David Christoffersen

Disclaimer- not a sr Dev.
But No: 3 is so much more then just β€œdon’t have time” - our sr devs usually understand that customization carries hidden costs- and plain implementations are cheaper. Nothing is worse then superOptimized systems. They are heavy on support, upgrading, ramping up new members. Sr devs usually understands this. It’s the same with adding extra modules - it carries a cost-

Collapse
rbseaver profile image
Rob Seaver (He/him)

I don't know what twenty years counts for, but I feel all six of these very, very deeply. Thank you for sharing and letting some of us know we're not alone!

Collapse
shubhambattoo profile image
Shubham Battoo

Very relatable for a person trying to transition slowly into a senior dev.

Collapse
rodrigovallades profile image
Rodrigo Vallades • Edited on

Remotely comparing that something negative is for "sissies", in this day and age, is very unfortunate. I lost interest in reading the rest of the article after reading this nonsense.

Collapse
codemouse92 profile image
Jason C. McDonald Author • Edited on

It seems you skimmed a bit too quick and missed what was actually written. Allow me to help you by adding emphasis to the quote:

A lot of junior developers seem to be under the impression that conditional statements are for sissies and n00bs. Nothing could be further from the truth!

As a rule, it's wise to slow down and carefully re-read statements before reacting to them.

Collapse
mellen profile image
Matt Ellen

I mean... the way it's phrased you're still using a negative term for effeminate men (i.e. sissy) and making it seem like a bad thing. I know that's not how you meant it to come out, but that's how it reads.

In over explained terms:

Saying "X is for sissies" when one means "X is bad" means that one means sissies are bad. Saying "junior devs think X is for sissies" does not remove the negative connotation. Also, since you can't know what junior devs think (unless you have some kind of super power), you're saying you think sissies are bad. Adding "Nothing could be further from the truth" only reinforces the negative connotation, because you're denying that X is bad, not denying that sissies are bad.

Thread Thread
codemouse92 profile image
Jason C. McDonald Author • Edited on

I literally do know what junior developers think. I mentor them 1 on 1 on practically a daily basis. This stuff comes up. But that's not where the term usage here comes from.

First, being a "n00b" isn't bad either. There is an implied "only" there, and retrospectively, the message would be clearer with it there. Syntactic error.

Second, I did not know the new connotation of "sissies". I've never applied it anything myself, although I grew up HEARING it used. Thus, the usage here was a deliberate reference to how lots of boys will irrationally claim that perfectly normal things are "only for girls" and "only for sissies" because they think, wrongly, that common sense detracts from their "tough" image. Think "The Sandlot". It was meant to imply that sort of misperception.

But, since it's clearly a point of contention, I've revised.

EDIT: I know why I'm baffled now! I never even implied that ANYTHING was "bad" in that paragraph. The misperception I describe explicitly reads as "if statements are not for rugged, experienced developers." The "bad" part had to be read in, which puts the perception question back on YOU, the reader.

Collapse
felixlovecode profile image
Felix Love Code

I'm a senior fresher, for sure :D

Collapse
oneguycoding profile image
Steeve McCauley

Can we use goto yet?

Collapse
codemouse92 profile image
Jason C. McDonald Author

If you know why you shouldn't use goto, you may use goto.

Collapse
cristiancastrodc profile image
cristiancastrodc

Great list!
I have 6 years of experience and point 6 is really true.
I don't feel like a senior dev and I don't know if I will ever feel like that with so many things to learn every day!

Collapse
makeavoy profile image
Nick McAvoy

This is pretty hopeful, It's just too bad all the jobs out there are for senior devs

Collapse
codemouse92 profile image
Jason C. McDonald Author

Not at all. I've come across more mid-level jobs than senior ones.

πŸ‘€ Just want to lurk?

Β 
That's fine, you can still create an account and turn on features like 🌚 dark mode.