30 ms·

Mindsets to Avoid as a Senior Software Developer

93 points by sidcool 6y ago

apples_oranges 6y ago
There is a quote about progress depending on the old folks who cling to an old way to see the world, to die. (But I can't find it.) But with regards to programming: Where do you think is the negativity about progress coming from? A feeling that skills once learned with difficulty are becoming obsolete?
- KittenInABox 6y ago
  Science advances one funeral at a time?
- nitrogen 6y ago
  A feeling that skills once learned with difficulty are becoming obsolete? It's seeing every tiny bit of progress accompanied by ten steps backward as a new language community re-solves and then re-breaks things that were already figured out by other ecosystems. Most "progress" is just going in circles with NIH syndrome, plus a bit of counterproductive cargo culting whatever some famous company does. New science is only accepted if it does a better job of explaining old problems and anticipating new ones. Every new tech should have to justify itself in the same way. If it's not giving you a clear superpower over what already exists, it's not worth using. If it does, then adopt it ASAP.
  - Kaze404 6y ago
    That's a very narrow minded view of technology in my opinion. People can create, re-solve and re-break whatever they want. If an unproven and untested technology makes its way into a system you deem critical, that's a flaw of management not of the technology itself.
    - nitrogen 6y ago
      People can create, re-solve and re-break whatever they want. I agree with you here. On my own time I'm just now reimplementing a bunch of audio algorithms in nearly pure Ruby with a DSL just for fun and learning. But I'm not going to go give speeches about how much better the new way is than the old way, how anyone fighting my code is just a luddite who resists progress and is afraid to learn, and how all the doubters are on the wrong side of history.
      - Kaze404 6y ago
        That's fair enough. I think we agree that there needs to be a balance between the weird evangelism of new tools (I literally have psychological damage as consequence of previous experience with a Medium-obsessed CTO) and the cynicism I often see when it comes to those same new tools.
- Scarblac 6y ago
  Planck's principle: https://en.wikipedia.org/wiki/Planck%27s_principle https://en.wikipedia.org/wiki/Planck%27s_principle A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it. . . . An important scientific innovation rarely makes its way by gradually winning over and converting its opponents: it rarely happens that Saul becomes Paul. What does happen is that its opponents gradually die out, and that the growing generation is familiarized with the ideas from the beginning: another instance of the fact that the future lies with the youth. — Max Planck, Scientific autobiography, 1950, p. 33, 97 Informally, this is often paraphrased as "Science progresses one funeral at a time".
- hinkley 6y ago
  Software is not really one field though, and you can pick and choose which 'tribe' you belong to. What's happening at insurance companies has very little to do with your day-to-day.
aequitas 6y ago
One thing I've learning is code review should never be used just as gate-keeping for the senior developers. Rather, let everyone (juniors, QA, non-developers) in the team perform reviews of everyones code, even your senior code. Not only is it a great way to spread/communicate knowledge and understanding in the team. But everyone looks at your code with a different eye and background. You may have written the greatest opus magnum of your programming career. But if the junior or medior can't make sense of it, they will not be able to maintain it when you're gone. So effectively you have failed.
- capableweb 6y ago
  > You may have written the greatest opus magnum of your programming career. But if the junior or medior can't make sense of it, they will not be able to maintain it when you're gone. So effectively you have failed. Overall I agree with you, yeah. But also no. Of course the code should be as simple to understand as possible, but if the junior or medior doesn't understand matrices, nothing I do will make them understand them. So I mean, yes, but also no. Sometimes it's OK to expect people to have some domain knowledge. Doesn't mean your code should be spaghetti of course.
  - ramy_d 6y ago
    yeah I would say in principle this makes sense but in practice a junior will typically say "this is beyond me but you're the senior so if it works, it works!" It is an opportunity to go through the code and concepts at least.
  - aequitas 6y ago
    Maybe they don't have to understand the detailed inner workings of an algorithm and such. But they should be able to deal with that piece of code in abstract. A good comment on what a piece of code is intended to do is perfectly fine to know it's place in a greater whole. Not every developer knows how crypto functions work, but they can make good decisions on how these functions should fit in certain logical scenarios or if an implementation is badly written/documented.
  - efsavage 6y ago
moksly 6y ago
Where are young developers less productive than their seniors? People are literally building successful companies on the fact that if you set up an university like environment, have foosball, tech-interest-talk and pizza nights, then you can hire a bunch of fresh developers who will work a lot of extra and free hours for you because they are young. Quality typically needs a few years of real world experience, but quality is honestly often an after thought in most companies. The real value of good senior developers is their ability to make haste slowly. Especially in enterprise organisations.
- mlthoughts2018 6y ago
  Most of the companies you’re describing fold and fail miserably after just a few years. Only very, very, very, very, very few of them achieve any kind of significant funding or market success. I wonder why?
  - ativzzz 6y ago
    Code quality has nothing to do with the success of the vast majority of businesses
    - jacobsenscott 6y ago
      Business seldom fail for a single reason, but poor code quality can be a major contributor to failure. Do you need to pay 20 programmers rather than 10? Do you have a higher customer turnover rate because they encounter too many bugs and lose trust in the system? Do you lose out on sales because you can't close the feature gaps with your competitors? Are you unable to respond to customer support requests in a timely fashion because there are too many, or fixing the problems is really hard?
      - thinkingkong 6y ago
        Parent said vast majority and they're correct. As a corollary I've seen companies with impeccable code bases fail dramatically.
NotPavlovsDog 6y ago
I would like to take the parent topic a step forward and add "Mindsets to pursue as a Software Developer, regardless of rank". To add: What are my blind-spots? Actively seek and solicit contrarian viewpoints, contradictory to ingrained paradigms. Look for unquestioned self-beliefs, with dedicated time plan and check-lists. As a personal example, the Lisp legacy has made me reconsider not just memory management, but default behavior when a program crashes, system design and, ultimately, the interplay between mathematics, CS and UX. As a follow-up, the legacy of Douglas Engelbart. He demonstrated the computer mouse, hypertext, networked computers and face-to face conferencing, including shared workflow, in 1968 ![ https://en.wikipedia.org/wiki/Douglas_Engelbart https://en.wikipedia.org/wiki/Douglas_Engelbart ]. This was not mentioned in popular resources nor courses I took. I have learned a lot from this case, such as what being a true visionary vs marketer means and entails. I would have missed this entirely had I not allocated time and dedicated schedule towards a mindset of actively seeking contrarian view-points and historical perspectives. Dedicate time to self-review, including value alignment and career goals, according to 1 year, 3 year, and 5 year plan(s). The bigger picture, such as taking the time to review if the software one is producing aligns with own ethical values, and whether it meets own standards of engineering excellence, can often be muted by the mundane, the daily, and the profane/corporate.
zwieback 6y ago
The third one resonated with me. I have to resist the urge to recast any new thing I hear about in terms of the original languages I learned 30 years ago C++, Lisp, Fortran, Smalltalk and the OSes at the time VMS, Unix, Windows, OS/2. I feel like the basic problems we're solving are always the same but the ways we are solving them are always changing and I'm loving the way we're doing things now as much or more as we used to. I think a lot of people in my age group are more resentful or just resisting change.
- falcolas 6y ago
  The paradigms are remarkably similar, the implementations are different. Understanding how they're the same and why they're different; both are valuable.
- jacobsenscott 6y ago
  No doubt there have been great improvements in software development tools and languages. But it also take experience to differentiate between the hype and FUD, and true advances. As a senior dev pushing back against FOMO driven development and resume padding is exhausting.
iio7 6y ago
I wish we would stop comparing young vs old, this vs that and then just help each other and respect each other. Everyone has something to contribute, whether it is experience, energy, knowledge, etc. In my younger years I worked on a project with a much older guy and he was extremely meticulous to the point where it was really really difficult to stay patient. However, I learned that he did that out of several decades of experience, and that getting the stuff right from the beginning saved us tons of hours of work later.
collyw 6y ago
He doesn't sound so senior. What can I do in Python 3 that I wasn't doing a decade ago in Perl 5?
- buescher 6y ago
  He sounds like a pretty typical C++ programmer of the 1990-2010 era. For a lot of people, learning C++ was a difficult enough accomplishment that they tended to think of professional progamming as synonymous with C++. Give the dude credit for getting past that.
yakshaving_jgt 6y ago
> However, software development is an ever-changing field. I don't buy this, or at best it's only very superficially true. The Hypertext Transfer Protocol is the same as it ever was. Computer science is all fundamentally the same. The languages, paradigms, editors, and operating systems we all use are decades old. > Python, what is it? No {} and, it’s optional to use ;? Using indentation is a must?? I think this somewhat proves my point.
deleted 6y ago
[deleted]
mhitza 6y ago
I actually disagree on the third point. I'm back at implementing web design the same way I used to do them back in 2007. Sure, instead of tables I'm using div + flex and instead of inline styles I'm using utility first CSS. For all intents and purposes it's exactly the same process, with just another coat of paint. The major difference is that back then in order to write terse CSS I memorized all the short forms, whereas nowadays I'd have to look those up.
- corebuffer 6y ago
  I think third point is more on not despising new tech, but I agree we should also remember not to do the same to old tech. I learned a lot with Forth, which is older than me. While that is true, I can't also deny that Rust improves a lot on embedded development and is newer. While I can argue that using Forth or C is possible and simpler/easier, the lesson seems to be that ignoring Rust isnt a good idea. IMO its like you can keep using raw CSS instead of the latest hype, but the key is not to ignore and always evaluate new things with the same care as you did to old ones. :) (at least that is how I understood it)
StillBored 6y ago
"New Tech Is Just Recycled Old Tech" Without quoting the entire paragraph, I'm not sure "C" has ever been the mainstream choice. At nearly every point in the history of C, there has been a "better" or more popular language. Be that jcl, cobol, fortran, visual basic, java, python, php, C#, etc. C/C++ are systems programming languages, they are the underlying technology supporting all the business and application development. Even when I did less pure system programming, our applications were frequently split into a lower level/server/etc portion and the higher level user facing code. The former was written in a high perf compiled language, the user facing code was generally written in a higher level language. And that is still true today, it takes very little google foo, to find project after project which decided they needed higher perf/more efficiency and rewrote the core data handling in C. Even in cases where C/C++ weren't the obvious choices (https://github.com/sass/libsass https://github.com/sass/libsass). And yes, sometimes one ends up picking a chain of subpar languages and rotating them du-jour. But in that direction you get trapped on both some language everyone hates (facebook/php anyone? although to be fair facebook has made php one of the better choices these days) So much so, that if I were to start another mobile application, I would probably use one of the C++ based toolkits. Because those are the only choices that provide good cross platform UI's that are performant. For everything else I would probably just write a web application with decent local storage caching/etc. So, its probably an unpopular opinion, but as a senior developer, I think the ability to make unpopular choices, particularly when it comes to language and toolkits is one of my strongest attributes. Rarely will you find me picking something like react-native (or electron) for mobile apps because i've yet to see a case were the benefits actually outweighed the negatives. Similarly for native toolkits tied to a particular platform because i've yet to work anywhere that could legitimately afford to double (or worse) their engineering efforts by writing the same application multiple times.
legerdemain 6y ago
A person with the job title "senior developer" has, what, 3-5 years of full-time work experience? So instead of being 21 and bushy-tailed, they're 24-26 and only slightly less bushy-tailed. They're still working through the maladies of youth, like absolute opinions, rabbit-holing, perfectionism, zealotry, and over-identifying with their work. A young person might need 10 years or more to develop a balance of caring and DGAF skills. And some people stay insufferable forever!
Justsignedup 6y ago
One thing I learned is that there are definitely amazing tools being built for solving lots of problems I had to solve in the past. The problem is orchestrating those tools. Sometimes the low-tech simple solution works. Sometimes its time to throw it out and use a framework / tool. Flexibility is everything.
hodgesrm 6y ago
The single biggest thing I've learned is to value the skills of people who are not software engineers. For example, it's a joy to see a great salesperson at work. The best of them have incredible listening skills that allow them to connect user problems with vendor solutions, plus the persistence to bull through obstacles to make customers happy.
ivan_ah 6y ago
I'd like to add a fourth mindset that I have found to be very useful: try to keep the beginner mindset, even as you become more and more experienced. As a (motivated) beginner, you're expect to fail, and fail repeatedly, and such setbacks do not affect you emotionally. Of course things won't work the first time—the key is to stick with it until it works. However with experience and "seniority" people develop expectations of themselves: about speed, about best practices, about performance, or any number of other methodologies. Basically, you expect a lot of yourself. These expectations often have the effect of slowing down exploration (i.e. I'm going to do it right the first time) and can lead to negative-valence feelings when things don't work out (e.g. you have an unproductive day, run into lots of bugs, or can't figure something out). A beginner will be fine with such setbacks because they don't have a big ego, but a "senior" developer will be—literally—hurt by such setbacks, and they shouldn't be. It's all good. Failure is normal. Just get up and try again.

93 points by sidcool 6y ago

There is a quote about progress depending on the old folks who cling to an old way to see the world, to die. (But I can't find it.) But with regards to programming: Where do you think is the negativity about progress coming from? A feeling that skills once learned with difficulty are becoming obsolete?

KittenInABox 6y ago
Science advances one funeral at a time?
nitrogen 6y ago
A feeling that skills once learned with difficulty are becoming obsolete? It's seeing every tiny bit of progress accompanied by ten steps backward as a new language community re-solves and then re-breaks things that were already figured out by other ecosystems. Most "progress" is just going in circles with NIH syndrome, plus a bit of counterproductive cargo culting whatever some famous company does. New science is only accepted if it does a better job of explaining old problems and anticipating new ones. Every new tech should have to justify itself in the same way. If it's not giving you a clear superpower over what already exists, it's not worth using. If it does, then adopt it ASAP.
- Kaze404 6y ago
  That's a very narrow minded view of technology in my opinion. People can create, re-solve and re-break whatever they want. If an unproven and untested technology makes its way into a system you deem critical, that's a flaw of management not of the technology itself.
  - nitrogen 6y ago
    People can create, re-solve and re-break whatever they want. I agree with you here. On my own time I'm just now reimplementing a bunch of audio algorithms in nearly pure Ruby with a DSL just for fun and learning. But I'm not going to go give speeches about how much better the new way is than the old way, how anyone fighting my code is just a luddite who resists progress and is afraid to learn, and how all the doubters are on the wrong side of history.
    - Kaze404 6y ago
      That's fair enough. I think we agree that there needs to be a balance between the weird evangelism of new tools (I literally have psychological damage as consequence of previous experience with a Medium-obsessed CTO) and the cynicism I often see when it comes to those same new tools.
Scarblac 6y ago
Planck's principle: https://en.wikipedia.org/wiki/Planck%27s_principle https://en.wikipedia.org/wiki/Planck%27s_principle A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it. . . . An important scientific innovation rarely makes its way by gradually winning over and converting its opponents: it rarely happens that Saul becomes Paul. What does happen is that its opponents gradually die out, and that the growing generation is familiarized with the ideas from the beginning: another instance of the fact that the future lies with the youth. — Max Planck, Scientific autobiography, 1950, p. 33, 97 Informally, this is often paraphrased as "Science progresses one funeral at a time".
hinkley 6y ago
Software is not really one field though, and you can pick and choose which 'tribe' you belong to. What's happening at insurance companies has very little to do with your day-to-day.

aequitas 6y ago

One thing I've learning is code review should never be used just as gate-keeping for the senior developers. Rather, let everyone (juniors, QA, non-developers) in the team perform reviews of everyones code, even your senior code. Not only is it a great way to spread/communicate knowledge and understanding in the team. But everyone looks at your code with a different eye and background. You may have written the greatest opus magnum of your programming career. But if the junior or medior can't make sense of it, they will not be able to maintain it when you're gone. So effectively you have failed.

capableweb 6y ago
> You may have written the greatest opus magnum of your programming career. But if the junior or medior can't make sense of it, they will not be able to maintain it when you're gone. So effectively you have failed. Overall I agree with you, yeah. But also no. Of course the code should be as simple to understand as possible, but if the junior or medior doesn't understand matrices, nothing I do will make them understand them. So I mean, yes, but also no. Sometimes it's OK to expect people to have some domain knowledge. Doesn't mean your code should be spaghetti of course.
- ramy_d 6y ago
  yeah I would say in principle this makes sense but in practice a junior will typically say "this is beyond me but you're the senior so if it works, it works!" It is an opportunity to go through the code and concepts at least.
- aequitas 6y ago
  Maybe they don't have to understand the detailed inner workings of an algorithm and such. But they should be able to deal with that piece of code in abstract. A good comment on what a piece of code is intended to do is perfectly fine to know it's place in a greater whole. Not every developer knows how crypto functions work, but they can make good decisions on how these functions should fit in certain logical scenarios or if an implementation is badly written/documented.
- efsavage 6y ago

moksly 6y ago

Where are young developers less productive than their seniors? People are literally building successful companies on the fact that if you set up an university like environment, have foosball, tech-interest-talk and pizza nights, then you can hire a bunch of fresh developers who will work a lot of extra and free hours for you because they are young. Quality typically needs a few years of real world experience, but quality is honestly often an after thought in most companies. The real value of good senior developers is their ability to make haste slowly. Especially in enterprise organisations.

mlthoughts2018 6y ago
Most of the companies you’re describing fold and fail miserably after just a few years. Only very, very, very, very, very few of them achieve any kind of significant funding or market success. I wonder why?
- ativzzz 6y ago
  Code quality has nothing to do with the success of the vast majority of businesses
  - jacobsenscott 6y ago
    Business seldom fail for a single reason, but poor code quality can be a major contributor to failure. Do you need to pay 20 programmers rather than 10? Do you have a higher customer turnover rate because they encounter too many bugs and lose trust in the system? Do you lose out on sales because you can't close the feature gaps with your competitors? Are you unable to respond to customer support requests in a timely fashion because there are too many, or fixing the problems is really hard?
    - thinkingkong 6y ago
      Parent said vast majority and they're correct. As a corollary I've seen companies with impeccable code bases fail dramatically.

NotPavlovsDog 6y ago

I would like to take the parent topic a step forward and add "Mindsets to pursue as a Software Developer, regardless of rank". To add: What are my blind-spots? Actively seek and solicit contrarian viewpoints, contradictory to ingrained paradigms. Look for unquestioned self-beliefs, with dedicated time plan and check-lists. As a personal example, the Lisp legacy has made me reconsider not just memory management, but default behavior when a program crashes, system design and, ultimately, the interplay between mathematics, CS and UX. As a follow-up, the legacy of Douglas Engelbart. He demonstrated the computer mouse, hypertext, networked computers and face-to face conferencing, including shared workflow, in 1968 ![ https://en.wikipedia.org/wiki/Douglas_Engelbart https://en.wikipedia.org/wiki/Douglas_Engelbart ]. This was not mentioned in popular resources nor courses I took. I have learned a lot from this case, such as what being a true visionary vs marketer means and entails. I would have missed this entirely had I not allocated time and dedicated schedule towards a mindset of actively seeking contrarian view-points and historical perspectives. Dedicate time to self-review, including value alignment and career goals, according to 1 year, 3 year, and 5 year plan(s). The bigger picture, such as taking the time to review if the software one is producing aligns with own ethical values, and whether it meets own standards of engineering excellence, can often be muted by the mundane, the daily, and the profane/corporate.

zwieback 6y ago

The third one resonated with me. I have to resist the urge to recast any new thing I hear about in terms of the original languages I learned 30 years ago C++, Lisp, Fortran, Smalltalk and the OSes at the time VMS, Unix, Windows, OS/2. I feel like the basic problems we're solving are always the same but the ways we are solving them are always changing and I'm loving the way we're doing things now as much or more as we used to. I think a lot of people in my age group are more resentful or just resisting change.

falcolas 6y ago
The paradigms are remarkably similar, the implementations are different. Understanding how they're the same and why they're different; both are valuable.
jacobsenscott 6y ago
No doubt there have been great improvements in software development tools and languages. But it also take experience to differentiate between the hype and FUD, and true advances. As a senior dev pushing back against FOMO driven development and resume padding is exhausting.

iio7 6y ago

I wish we would stop comparing young vs old, this vs that and then just help each other and respect each other. Everyone has something to contribute, whether it is experience, energy, knowledge, etc. In my younger years I worked on a project with a much older guy and he was extremely meticulous to the point where it was really really difficult to stay patient. However, I learned that he did that out of several decades of experience, and that getting the stuff right from the beginning saved us tons of hours of work later.

collyw 6y ago

He doesn't sound so senior. What can I do in Python 3 that I wasn't doing a decade ago in Perl 5?

buescher 6y ago
He sounds like a pretty typical C++ programmer of the 1990-2010 era. For a lot of people, learning C++ was a difficult enough accomplishment that they tended to think of professional progamming as synonymous with C++. Give the dude credit for getting past that.

yakshaving_jgt 6y ago

> However, software development is an ever-changing field. I don't buy this, or at best it's only very superficially true. The Hypertext Transfer Protocol is the same as it ever was. Computer science is all fundamentally the same. The languages, paradigms, editors, and operating systems we all use are decades old. > Python, what is it? No {} and, it’s optional to use ;? Using indentation is a must?? I think this somewhat proves my point.

deleted 6y ago

[deleted]

mhitza 6y ago

I actually disagree on the third point. I'm back at implementing web design the same way I used to do them back in 2007. Sure, instead of tables I'm using div + flex and instead of inline styles I'm using utility first CSS. For all intents and purposes it's exactly the same process, with just another coat of paint. The major difference is that back then in order to write terse CSS I memorized all the short forms, whereas nowadays I'd have to look those up.

corebuffer 6y ago
I think third point is more on not despising new tech, but I agree we should also remember not to do the same to old tech. I learned a lot with Forth, which is older than me. While that is true, I can't also deny that Rust improves a lot on embedded development and is newer. While I can argue that using Forth or C is possible and simpler/easier, the lesson seems to be that ignoring Rust isnt a good idea. IMO its like you can keep using raw CSS instead of the latest hype, but the key is not to ignore and always evaluate new things with the same care as you did to old ones. :) (at least that is how I understood it)

StillBored 6y ago

"New Tech Is Just Recycled Old Tech" Without quoting the entire paragraph, I'm not sure "C" has ever been the mainstream choice. At nearly every point in the history of C, there has been a "better" or more popular language. Be that jcl, cobol, fortran, visual basic, java, python, php, C#, etc. C/C++ are systems programming languages, they are the underlying technology supporting all the business and application development. Even when I did less pure system programming, our applications were frequently split into a lower level/server/etc portion and the higher level user facing code. The former was written in a high perf compiled language, the user facing code was generally written in a higher level language. And that is still true today, it takes very little google foo, to find project after project which decided they needed higher perf/more efficiency and rewrote the core data handling in C. Even in cases where C/C++ weren't the obvious choices (https://github.com/sass/libsass https://github.com/sass/libsass). And yes, sometimes one ends up picking a chain of subpar languages and rotating them du-jour. But in that direction you get trapped on both some language everyone hates (facebook/php anyone? although to be fair facebook has made php one of the better choices these days) So much so, that if I were to start another mobile application, I would probably use one of the C++ based toolkits. Because those are the only choices that provide good cross platform UI's that are performant. For everything else I would probably just write a web application with decent local storage caching/etc. So, its probably an unpopular opinion, but as a senior developer, I think the ability to make unpopular choices, particularly when it comes to language and toolkits is one of my strongest attributes. Rarely will you find me picking something like react-native (or electron) for mobile apps because i've yet to see a case were the benefits actually outweighed the negatives. Similarly for native toolkits tied to a particular platform because i've yet to work anywhere that could legitimately afford to double (or worse) their engineering efforts by writing the same application multiple times.

legerdemain 6y ago

A person with the job title "senior developer" has, what, 3-5 years of full-time work experience? So instead of being 21 and bushy-tailed, they're 24-26 and only slightly less bushy-tailed. They're still working through the maladies of youth, like absolute opinions, rabbit-holing, perfectionism, zealotry, and over-identifying with their work. A young person might need 10 years or more to develop a balance of caring and DGAF skills. And some people stay insufferable forever!

Justsignedup 6y ago

One thing I learned is that there are definitely amazing tools being built for solving lots of problems I had to solve in the past. The problem is orchestrating those tools. Sometimes the low-tech simple solution works. Sometimes its time to throw it out and use a framework / tool. Flexibility is everything.

hodgesrm 6y ago

The single biggest thing I've learned is to value the skills of people who are not software engineers. For example, it's a joy to see a great salesperson at work. The best of them have incredible listening skills that allow them to connect user problems with vendor solutions, plus the persistence to bull through obstacles to make customers happy.

ivan_ah 6y ago

I'd like to add a fourth mindset that I have found to be very useful: try to keep the beginner mindset, even as you become more and more experienced. As a (motivated) beginner, you're expect to fail, and fail repeatedly, and such setbacks do not affect you emotionally. Of course things won't work the first time—the key is to stick with it until it works. However with experience and "seniority" people develop expectations of themselves: about speed, about best practices, about performance, or any number of other methodologies. Basically, you expect a lot of yourself. These expectations often have the effect of slowing down exploration (i.e. I'm going to do it right the first time) and can lead to negative-valence feelings when things don't work out (e.g. you have an unproductive day, run into lots of bugs, or can't figure something out). A beginner will be fine with such setbacks because they don't have a big ego, but a "senior" developer will be—literally—hurt by such setbacks, and they shouldn't be. It's all good. Failure is normal. Just get up and try again.