Important, Read This First
You’re about to read a blog post with a lot of advice. Learning from those who came before us is instrumental to success, but we often forget an important caveat. Almost all advice is contextual, yet it is rarely delivered with any context.
“You just need to charge more!” says the company who has been in business for 20 years and spent years charging “too little” to gain customers and become successful.
“You need to build everything as microservices!” says the company who built a quick monolith, gained thousands of customers, and then pivoted into microservices as they started running into scaling issues.
Without understanding the context, the advice is meaningless, or even worse, harmful. If those folks had followed their own advice early on, they themselves would likely have suffered from it. It is hard to escape this trap. We may be the culmination of our experiences, but we view them through the lens of the present.
So to give you a little context on where my advice comes from, I spent the first half of my career as a software engineer working for various small businesses and startups, then I went into consulting and worked in a number of really large businesses. Then I started Simple Thread and we grew from a team of 2 to a team of 25. 10 years ago we worked with mostly small/medium businesses, and now we work with a mix of big and small businesses.
My advice is from someone who…
- has almost always been on small, lean teams where we have to do a lot with very little.
- values working software over specific tools.
- is starting new projects all the time, but also has to maintain a number of systems.
- values engineer productivity over most other considerations
My experiences over the last 20 years have shaped how I view software, and have led me to some beliefs which I’ve tried to whittle down to a manageable list that I hope you find valuable.
On with the list
1. I still don’t know very much
“How can you not know what BGP is?” “You’ve never heard of Rust?” Most of us have heard these kinds of statements, probably too often. The reason many of us love software is because we are lifelong learners, and in software no matter which direction you look, there are wide vistas of knowledge going off in every direction and expanding by the day. This means that you can spend decades in your career, and still have a huge knowledge gap compared to someone who has also spent decades in a seemingly similar role. The sooner you realize this, the sooner you can start to shed your imposter syndrome and instead delight in learning from and teaching others.
2. The hardest part of software is building the right thing
I know this is cliche at this point, but the reason most software engineers don’t believe it is because they think it devalues their work. Personally I think that is nonsense. Instead it highlights the complexity and irrationality of the environments in which we have to work, which compounds our challenges. You can design the most technically impressive thing in the world, and then have nobody want to use it. Happens all the time. Designing software is mostly a listening activity, and we often have to be part software engineer, part psychic, and part anthropologist. Investing in this design process, whether through dedicated UX team members or by simply educating yourself, will deliver enormous dividends. Because how do you really calculate the cost of building the wrong software? It amounts to a lot more than just lost engineering time.
3. The best software engineers think like designers
Great software engineers think deeply about the user experience of their code. They might not think about it in those terms, but whether it is an external API, programmatic API, user interface, protocol, or any other interface; great engineers consider who will be using it, why it will be used, how it will be used, and what is important to those users. Keeping the user’s needs in mind is really the heart of good user experience.
4. The best code is no code, or code you don’t have to maintain
All I have to say is “coders gonna code.” You ask someone in any profession how to solve a problem, and they are going to err on the side of what they are good at. It is just human nature. Most software engineers are always going to err on the side of writing code, especially when a non-technical solution isn’t obvious. The same goes for code you don’t have to maintain. Engineering teams are apt to want to reinvent the wheel, when lots of wheels already exist. This is a balancing act, there are lots of reasons to grow your own, but beware of toxic “Not Invented Here” syndrome.
5. Software is a means to an end
The primary job of any software engineer is delivering value. Very few software developers understand this, even fewer internalize it. Truly internalizing this leads to a different way of solving problems, and a different way of viewing your tools. If you really believe that software is subservient to the outcome, you’ll be ready to really find “the right tool for the job” which might not be software at all.
6. Sometimes you have to stop sharpening the saw, and just start cutting shit
Some people tend to jump into problems and just start writing code. Other people tend to want to research and research and get caught in analysis paralysis. In those cases, set a deadline for yourself and just start exploring solutions. You’ll quickly learn more as you start solving the problem, and that will lead you to iterate into a better solution.
7. If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system
This is something I struggle with a lot as my responsibilities take me further and further from the day to day of software engineering. Keeping up with the developer ecosystem is a huge amount of work, but it is critical to understand what is possible. If you don’t understand what is possible and what is available in a given ecosystem then you’ll find it impossible to design a reasonable solution to all but the most simple of problems. To summarize, be wary of people designing systems who haven’t written any code in a long time.
8. Every system eventually sucks, get over it
Bjarne Stroustrup has a quote that goes “There are only two kinds of languages: the ones people complain about and the ones nobody uses”. This can be extended to large systems as well. There is no “right” architecture, you’ll never pay down all of your technical debt, you’ll never design the perfect interface, your tests will always be too slow. This isn’t an excuse to never make things better, but instead a way to give you perspective. Worry less about elegance and perfection; instead strive for continuous improvement and creating a livable system that your team enjoys working in and sustainably delivers value.
9. Nobody asks “why” enough
Take any opportunity to question assumptions and approaches that are “the way things have always been done”. Have a new team member coming on board? Pay attention to where they get confused and what questions they ask. Have a new feature request that doesn’t make sense? Make sure you understand the goal and what is driving the desire for this functionality. If you don’t get a clear answer, keep asking why until you understand.
10. We should be far more focused on avoiding 0.1x programmers than finding 10x programmers
The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. I’ve seen programmers that sling 10x the amount of code, and then you have to fix it 10x the amount of times. The only way someone can be a 10x programmer is if you compare them to 0.1x programmers. Someone who wastes time, doesn’t ask for feedback, doesn’t test their code, doesn’t consider edge cases, etc… We should be far more concerned with keeping 0.1x programmers off our teams than finding the mythical 10x programmer.
11. One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be
Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all. If you are using your tools, and you don’t love or hate them in a myriad of ways, you need to experience more. You need to explore other languages, libraries, and paradigms. There are few ways of leveling up your skills faster than actively seeking out how others accomplish tasks with different tools and techniques than you do.
12. People don’t really want innovation
People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty. If you truly innovate, and change the way that people have to do things, expect mostly negative feedback. If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.
13. Your data is the most important part of your system
I’ve seen a lot of systems where hope was the primary mechanism of data integrity. In systems like this, anything that happens off the golden path creates partial or dirty data. Dealing with this data in the future can become a nightmare. Just remember, your data will likely long outlive your codebase. Spend energy keeping it orderly and clean, it’ll pay off well in the long run.
14. Look for technological sharks
Old technologies that have stuck around are sharks, not dinosaurs. They solve problems so well that they have survived the rapid changes that occur constantly in the technology world. Don’t bet against these technologies, and replace them only if you have a very good reason. These tools won’t be flashy, and they won’t be exciting, but they will get the job done without a lot of sleepless nights.
15. Don’t mistake humility for ignorance
There are a lot of software engineers out there who won’t express opinions unless asked. Never assume that just because someone isn’t throwing their opinions in your face that they don’t have anything to add. Sometimes the noisiest people are the ones we want to listen to the least. Talk to the people around you, seek their feedback and advice. You’ll be glad you did.
16. Software engineers should write regularly
Software engineers should regularly blog, journal, write documentation and in general do anything that requires them to keep their written communication skills sharp. Writing helps you think about your problems, and helps you communicate those more effectively with your team and your future self. Good written communication is one of the most important skills for any software engineer to master.
17. Keep your processes as lean as possible
Everyone wants to be agile these days, but being “agile” is about building things in small chunks, learning, and then iterating. If someone is trying to shoehorn much more into it than that, then they’re probably selling something. It isn’t to say that people don’t need accountability or help to work this way, but how many times have you heard someone from your favorite tech company or large open source project brag about how great their Scrum process is? Stay lean on process until you know you need more. Trust your team and they will deliver.
18. Software engineers, like all humans, need to feel ownership
If you divorce someone from the output of their work, they will care less about their work. I see this almost as a tautology. This is the primary reason why cross-functional teams work so well, and why DevOps has become so popular. It isn’t all about handoffs and inefficiencies, it is about owning the whole process from start to finish, and being directly responsible for delivering value. Give a group of passionate people complete ownership over designing, building, and delivering a piece of software (or anything really) and amazing things will happen.
19. Interviews are almost worthless for telling how good of a team member someone will be
Interviews are far better spent trying to understand who someone is, and how interested they are in a given field of expertise. Trying to suss out how good of a team member they will be is a fruitless endeavor. And believe me, how smart or knowledgable someone is is also not a good indicator that they will be a great team member. No one is going to tell you in an interview that they are going to be unreliable, abusive, pompous, or never show up to meetings on time. People might claim they have “signals” for these things… “if they ask about time off in the first interview then they are never going to be there!” But these are all bullshit. If you’re using signals like these you’re just guessing and turning away good candidates.
20. Always strive to build a smaller system
There are a lot of forces that will push you to build the bigger system up-front. Budget allocation, the inability to decide which features should be cut, the desire to deliver the “best version” of a system. All of these things push us very forcefully towards building too much. You should fight this. You learn so much as you’re building a system that you will end up iterating into a much better system than you ever could have designed in the first place. This is surprisingly a hard sell to most people.
What is your story?
So there you have it, 20 years of software distilled down into 20 pithy pieces of wisdom. I’d love to hear it if something resonated with you. I’d also love to hear if you have a piece of wisdom that you’ve picked up over your career that you’d like to share. Feel free to leave it down in the comments.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
You talk about interesting topics about software development process. It’s clear to understand how important are the communicational skill nowadays.
I love the ownership point, I totally agree with it.
Great post!
Hard disagree with most of the 20 items.
1. Writing software is difficult, tedious and needs real work. No silver bullet libraries, no methodology, no framework, no IOT, no amount of unit tests will get the work done faster.
2. Developers collect tools, libraries and pet technologies and make projects go over their time and budget by doing it.
3. Code should encapsulate algorithms and not be structured other wise. Code should follow the business logic and be readable and match business requirements easily.
4. Forgetting history keeps the productivity and industry down. Microsoft re-discovering the same old technology which existed on 1960s mainframes for the 7th time just to sell products, trademark buzzwords, training, certification and everything is an anchor around the modern developer’s neck. Think file transfer -> X12 -> serial communication -> raw socket packets -> corba -> xml soap -> xml http -> Rest JSON http -> gRpc as a 50 year journey of rediscovering the same thing repeatedly, each not really that much better than the older technologies, wrapping mounds of interlarded crud on top of fragile, hard to program libraries and the square peg in a round hole mismatch.
5. Refusing to hold W3C and large tech companies accountable for not fixing web HTTP, HTML, CSS and JavaScript for 25+ years.
– How can I create a control which has HTML, CSS, JS which has encapsulated CSS, encapsulated HTML, encapsulated JS without a 10,000 file framework?
– How to match HTML DOM elements with JS without using quoted magic strings? Quoted magic strings were proven anti-productivity and anti-quality in the 1960s
– How to have a UI without the everything is a call back and function pointer? Function pointers with modern wrappings are just as bad as the 1060s computed jump to function tables
6. Forgetting that tech is a business with a 7 year hype cycle, with the new thing being embryonically hyped for 2 years by cutting edge bloggers, then 2 years by sales marketing of companies, then 3 years of disappointment for companies trying to implement it. Followed by, abandonment when the ROI does not work out. Resume driven development, just for business persons.
And yes, there’s a new hype every 2 years to waste time and money on
7. Not holding tech companies accountable when they release major products, .net core, which have less than a 5 year full support lifecycle. Long term support .net is under 3 years.
That is a forced upgrade every 3 years for every .net system just to pass the IT auditors at a large company
8. Devaluing your own worth and work as a developer by telling everyone that the proposed product/task is easy. Software dev is hard work, less than 1 of a 1000 people can even do it poorly.
I would not go to a brain surgeon that told everyone that what he does is easy.
9. Forgetting that software development is a hard, tedious, isolated job where people desiring lots of human interaction will rapidly leave the field by their own choice and lots of people not getting into the field by their own choice.
10. Not telling people that you as a developer have to say “No, it’s too expensive” or “No, it’s too risky” as a regular part of your job. Persons not developing software treating you poorly with career ending consequences just because you won’t accept the death march cross to bear of impossible requirements of an impossibly short deadline
11. Not helping your fellow developers out. Speak well of your co-developers, team, and industry. Don’t downplay the difficulty, complexity or contribution of software.
12. Not calling people out when they think that more data, metrics for everything will automatically solve problems. Ask for a business case, ask for the questions they want to answer (in written form), get the business case and questions they want to answer from the requestor, make sure they are approved before committing to a tight deadline
13. Not damaging the next developer on your project – too many technologies, framework of the month, just another nuget package, one more class, have another 3 patterns, data on disk, data in database structure and consistency is not important and, yes, this system will never receive/send upstream/downstream data
14. Accepting code without parameter checking, error handling or in-line comment documentation (*cough* vendor’s happy path ‘doc’ page or *cough* signature only documentation with no example code or error handling.)
15. Misguided acceptance that best practices are best and not just a short nicely sized blog entry. Best practices, in many cases, do not scale for large 1,000,000+ line of code systems and make maintenance harder.
16. Not challenging the ‘more technology is better’ approach
I think you’ve been hurt too many times, boss. Just picking one at random, I would question “Best practices, in many cases, do not scale for large 1,000,000+ line of code systems and make maintenance hard”. The ‘beat practices’ I know of, by definition, are those that help with that.
I’m glad I clicked this article even though I felt I’ll probably regret it as most listicles with similar titles are bound to disappoint.
This one though, this was a true gem. Brown painted gold so to say.
And I want to thank you for it. Will try to keep your advice close to heart in the future, just started my first engineer position this spring.
Thank you Dom, I appreciate it!
Dom sums up my thoughts precisely – this is just about the first “list of N things” I’ve seen which I’ve actually thought worthwhile to spread to my networks. It would have saved us a lot of time if we’d had this when creating our Principal Engineers charter 🙂
I wrote my first codein 1982, and I fully agree that this is brown colored gold.
I resonate with point #19,
I am a recent graduate and I’m trying to land a job as a software engineering role. It has been very hard and I know I can be a great asset to a team, I am always reading, learning new things and I have a experience with clients and leadership. Not long ago I had an interview and I believed I did a pretty good job, however I didn’t get the role. I guess the are looking for the perfect programmer who doesn’t make mistakes.
By the way, I would I appreciate any help in my job search if anyone can help me. Thank you guys.
Email: giovannyqtech@gmail.com
Are there any aspects of the interview process you struggle with? Getting your first position can be tough because they don’t have the portfolio available to them as they would if you have years of experience. My advice? Create them that portfolio. Most jobs I have landed started because recruiters and such were browsing my git hub. There is enough value in that, some use it as their primary metric for determining competency.
Gio – I’m sending an email your way too, but want to make this public as well.
I am in no way affiliated, and honestly used it only a few times, however this is without a doubt the best tool I ever encountered when trying to level up my interviewing (which is different than working, as we all know).
Interviewing.io
I never paid a dime for the service, so again, YMMV, but live interviews and studying other live interviews is where it truly is at.
Good luck
“The only way someone can be a 10x programmer is if you compare them to 0.1x programmers. Someone who wastes time, doesn’t ask for feedback, doesn’t test their code, doesn’t consider edge cases, etc…”
This resonated very strongly iwth me. It’s me, I’m the 0.1 programmer :/
I am currently working on two projects, one that I enjoy and another one that I hate. I am a 2x programmer on the first and a 0.1x programmer on the second, and I am not able to change this, even though I try to.
Hey, take it easy. At work I’m sometimes a 0.1x programmer too. I felt pretty bad about it to be honest, like my coworkers were just a lot better than me. I started working on some things outside of work that I was really really interested in, and I noticed I was committing 10-15x more code per unit of time than I do at work — and it was good code, carefully written code that I was proud of and felt I wouldn’t be confused by at all if I came back to it in 2 years.
Don’t get yourself down, just keep looking for the role that brings out the best in you.
I think that probably the very fact that, you called yourself out as a “0.1x” programmer, means you could not possibly be 😉
You’re good bro. True 0.1x programmers don’t know they’re 0.1 😀
Thank you for this great article! It resonates very well with my own experiences from having worked as a developer. Many of these lessons applies to the entire field of software – one thing I missed was, to stop fixing someone else’s errors. That creates technical debt. If you make the error you have to fix it. It is an excellent learning opportunity. Also, if a vendor introduce a bug, we don’t make a workaround on behalf of the vendor. Use appropriate channels and make sure they clean up their issues.
Perfect. I’m signing it 🙂
AMAZING INSIGHTS
What a great post! I could relate to most of the points. It is for sure one of the best articles I’ve read which covers this particular topic. Thanks Justin for putting in the time and effort for sharing your thoughts.
Super insightful and totally true in my own 20yrs exp. It is the best 20yrs career advice in software engineering I ever read, I cant think of anything else… Thank you very much!
> biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be
I disagree with this: junior are more likely to repeat other’s opinions with convinction even though they haven’t experienced the issue that opinion was formed upon.
Also let’s remember that opinions are always subjective: humility and open-mindness are definitely something I want in senior peers and those quality are so rare that cannot be taken for granted.
—
I kind of agree with the following point
> If you are using your tools, and you don’t love or hate them in a myriad of ways, you need to experience more.
but I don’t think it’s telling if you’re senior or not.
You just have bad tools, like most ecosystems or you found yourself comfortable in your set of things and somebody else has found themselves comfortable in others.
Definitely against the
> I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all.
We’re building software. Violence should be as far away from us as possible. We’re not in trenches.
We’re too early in this discipline to feel like it’s a badge of honor to be entrenched on one side of the debate. We should try to be open mind and look for other point of view and respect others opinions.
> biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be
You are right, but also that’s not really the essence of what he was saying. I’m sure you probably realise this as well. Sure Juniors have “opinions”, but they won’t hold up to any amount of interrogation. Most seniors will have reasons, backed by experience.
It’s usually easy to figure out the difference between someone who was told an opinion and someone who formed one. So I still think the authors sentiment holds.
—
> If you are using your tools, and you don’t love or hate them in a myriad of ways, you need to experience more.
I don’t think the idea is that your current set of tools are the problem. It’s more that you haven’t looked around at all. Now if you love your tools and their productive, by all means. However, I would say it’s accurate that you can’t say whether or not your tools are good or bad if you haven’t tried others and started understanding the pros and cons. So in that sense it can show seniority in the sense that, you have enough experience with multiple tools to form opinions regarding when they are good/bad.
—
> I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all.
Here I think you’re just taking his hyperbole too literal. I’m the author doesn’t actually advocate for violence. We’re all allowed some hyperbole, otherwise writing, reading and general communication would become rather dull.
I too would rather prefer disagreeing with someone, than having someone always go “Yea sure, that’s cool”. Some of the best ideas in software I’ve ever had came from “aggressively” arguing about solutions. Most of us are professionals and can separate the heated debates from personal matters.
Unless you get written up for aggressively arguing like i did
This is great article honestly.. I’ve always love tech stuffs.. learnt html and css a long time ago, few years ago I learnt to program Arduino using c++.. but my real goal is to become a full stack developer but it seems like there are endless tons of stuffs to learn from front end to backend and it’s quite overwhelming honestly. Keeping track of new tools too seems almost impossible… I get overwhelmed sometimes honestly..
I’d really appreciate being put on the right track..
Alec, stick in the word passionately for violently. Do you still disagree? Sorry, I think that was a silly critique.
What a fun treat to see your name on the byline! Hope you’re doing well friend.
Hey! Good to hear from you. Hope you’re doing well!
“Sometimes the noisiest people are the ones we want to listen to the least.”
I have seen so many of this over the years, and often the best i have learn is
from silent one.
Thanks Justin, great article!
As from 20y experience as a software engineer myself, I can add one more thing which I have learned.
#21 Love your co-workers, or leave!
I’ve found that to be productive and to be able to create fantastic value, I do not function very well (or at all to be more honest) if fellow co-workers / team-members are rude or inpolite. As an introvert (like the best software nerds usually are), I have not (and still do not) have the habit to defend my self or “kick back”, when ever an outrovert claim the ether during an entire lunch or a meeting, or even worse, is trying to be funny and give jokes that to me often are insulting (even it might not was intended to be!). When hiring, the most important qualification in my opinion, is how humble, polite and positive the attitude the candidate is. Bad attitude, negativism is poison! I tend to leave (any company) when I feel there is too much “poison” around, and that has been a successful strategy (at least) for me so far. Bottom line: find and stay in a team where you find love and passion in your co-workers, where you feel the optimism and positivity around you. Never allow people make you or your ideas less worthy. Your ideas or code may be optimized, but if people around you communicate this to you in a way that makes you feel bad, leave! Make sure to surround you with fellow co-workers that point out how great even your worst piece of code is. Good colleges will complement you for how impressive it is, even they don’t understand anything of it! It is probably “messy” for many reasons and you of all know why, and if allowed, know hows to fix it, better than anyone.
Bottom line: Be aware of your social environment, you will only produce and feel happy about it when the environment allow you to do so! If the environment does not allow this, find a better environment that fits you!
Take this from a simple guy that have created software that is valued billions on Nasdaq today!
You’re actually deluded. You want people to be impressed at your worst code, and if not then they are toxic and you’ll just leave?
I think the real lesson here is to pamper your introvert coding magicians, they need to be protected from reality or they will stop working for you
Well, yes, in fact we will. The opportunities in software are too hot to pander to toxic engineering managers like you. Ever stopped to question why the average tenure in this field is like 2-3 years?
If you want to retain quality talent, respect is essential. I doubt your performance evaluation by higher management will be stellar in a few cycles if this is how you see engineers under you.
I think the primary reason for that average (well at least for the first 5 years anyway) is because they can get big pay increases by moving to the next job.
However, if people are respected, loved and appreciated they will forgo the big pay increases and stay. Unfortunately, few businesses realize this. The few who do benefit enormously.
> Make sure to surround you with fellow co-workers that point out how great even your worst piece of code is.
I’m going to disagree here. Peer review of code is important, and it’s only as good as it is honest. We need others to be honest in code review if we truly expect to improve and become a thriving team member. How that communication occurs must not be dysfunctional, judgemental or personal because that accomplishes nothing. For example, Linus Torvalds verbally abusing linux code contributers. Code review must simply be about the code and what’s best to solve the problem and how it fits in the rest of the system. Also, if you feel your solution is solid then articulate why in a calm confident way. Try not to be terrified of criticism, it just makes you unapproachable and distances you from the team.
If the work culture is toxic then by all means, I agree, look elsewhere. Just be sure you are making a fair assessment of others before packing up to move on and find the grass is not greener at the next organization. I have relatives who have been on that job hopping roller coaster and some of them are unable to hold onto jobs because they quickly become defensive and distance themselves.
I agree with this. I wouldn’t be half the developer I am today had I not had the luck to end up in a few teams where code reviews and discussions were open, direct, and no-holds-barred. Most of what I learn on the job comes from criticism on my code. And, as the article also points out, it’s not a seniority or experience issue. We all have different areas of expertise, and have a different collection of problems we’ve solved in the past. This is how that knowledge gets spread through the teams to make everyone better.
I’ve also been associated with teams who were focussing on being nice to each other. Whose code reviews felt more like a rote exercise in everybody making it a point to compliment each other and, if they really had to resort to pointing out something they’d change, hide it in between 10 comments about how great the code is in general.
One of the most important skills, in my opinion, is to learn how to distinguish between personal criticism, and objective discussions about the work. Our discussions could get pretty loud and heated at times (to the point of scaring some other employees and giving us quite a reputation). But it was okay because we all knew that we weren’t attacking each other personally, and we all got a long. After a heated debate, we would go out to have lunch together and talk as friends.
Bottom line, clear communication is crucial, even if it’s negative feedback. I don’t want to be writing crappy code and have nobody tell me that I am, and how I can fix it.
Oops, correction: not billions, sorry for getting carried away for a second there. It’s actually just a few $100 millions 🙂
Awesome article! I’ve been working on transitioning to software for a while now and I like to listen/read to seasoned professionals so that I can be more effective and take into account things I might be missing.
This is probably best article I have read in this topic and I’m glad I stumble upon it. Will share it with all my friends going thru the same motion of transitioning to tech.
As someone who “transitioned to software” shortly after I learned to walk, here’s an observation & suggestion.
So many people learn formulas or recipes and think they know technology. A monkey can see something done and repeat it. A parrot can hear something and repeat it. But they will be lost and frustrated if the parameters are changed slightly, or worse, if they need to combine elements of multiple skills into something new. You can be much more than a parrot or monkey if you choose to engage your human brain.
So I suggest this: learn what you need to know, and then find out what that is built upon, and learn that too. Go as deep as you can. Why does it work? When might it fail? Who knows about it? Answer these questions for yourself.
But don’t just focus on depth. Explore to the edges of your area, and look a little beyond them. What technical areas border your area of interest? What techniques do they have that might be useful in your area? What if you could combine areas? Is someone already doing that? What do you think is wrong with their approach, and can you improve upon it?
You mentioned reading what “seasoned professionals” write. This is a very good way to learn. Take a look at stack overflow, hacker news, and similar sites, and just binge-read the answers or comments from high-scoring people. There are also practice websites like project euler and hackerrank where you can test your skills against others and again learn from those who are further along on their journey.
Best of luck to you. This can be the most fun in the world, if you let it.
As a fellow 20 year journeyman developer I can definitely subscribe to these. #11, the difference between a junior developer and a senior developer is that a senior developer has already made all the mistakes a junior developer will make. A corollary to points #2, #5 and #13: Always strive to fully understand the business/problem domain before you write a single line of code. The flipside of #19, when changing jobs, one of the main questions you should ask from a company is to describe their onboarding processes — how much effort they’re willing to expend on training you is a good indication of whether they are hiring someone to make a contribution or a warm body to fill the headcount.
Hard to find anything in here that *doesn’t* resonate. This is one of the smartest, most useful blog posts on software development I’ve ever seen.
Having been at a few companies where the ‘big refactor’ to get rid of ‘tech debt’ was attempted, a lot of what you wrote resonated. I came to the saying, “Every line of code you write, that doesn’t eliminate more than one line of code, is you building your tech debt”. Its too easy to point to the ‘legacy’ system as ‘bad’ and start building the ‘good’ replacement and end up with 2x the code to maintain. This usually happens when you get to the final 5% of what the legacy system does, and just run out of time. I’ve been at companies where there are more than three systems, the legacy, the first refactor, the attempt at microservices and the team is busy working on the ‘final refactor’.
“Sometimes the noisiest people are the ones we want to listen to the least.”
I agree with the title of this paragraph, but this sentence stung a bit. It’s true there is a true mix of intra and extraverts on any given day in a tech org. But I have met some very vocal, outspoken devs, directors, CTOs who are very active and present and “noisy” in the organizations and in many cases I have been thankful and better off from their amplified presence in my career. I think we need to further define what you mean by “noisy”. 5 years ago I had a CTO (who still makes sure they code often), do a presentation about Redux (new kid on the block at the time), to 200 devs. That same CTO also did a great talk on Testing strategies a few months later that I found instrumental in my career when it comes to strategizing about testing. I would consider this person to be “noisy” and thankful that they were. But I am humble as well as noisy in my current org and am open to hear your thoughts on this subject.
Very well written points. I like all of these. I went through many of these and I understand how it feels.
Thank you.
I’ve been in the industry for over 20 years and #14 really hits home for me. I can’t count how many times someone with an affliction for “bright, shiny, new” things has wasted the time of the team and often the company while trying to make their favorite new technology of the week solve a problem that would have taken less time and effort to solve with what the team is already using. What these people are often lacking is the ability to really, thoroughly think things through to the end. The other thing that I see far too often is stagnation in learning. As you’ve said, to be in this field requires continual learning and people that refuse to accept that effectively tie themselves to the past and get left behind.
I personally refrain from using terms like “cutting shit”, those who use such words and speak this way believe it makes them sound cool or real (not sure what exactly) but to the receiving end it sounds disgusting and communicates disregard of others and quickly erodes the respect and opens the door wide open for even bigger (cool and real) things to occur
The more you think about a problem the better the solution. The better the why’s the smaller the solution. The more code you write the more the refactoring. You would at times be digging a hole to fill another and you need to come out sought of “unclutter” focus on the project otherwise you’ll scream micro service to every problem and keep at it till eventually you don’t understand what’s happening (possibly create a microservice to manage your microservice manager.. pun intended) …… Perfect read. Best developer blog I’ve read. Resonates to what’s happening in the field/industry even to DevOps engineers.
Hey there, this spurred a lot of discussion in my group. May I use it as part of a survey with quotes and attribution back to your site?
Justin, a warm shout from Stockholm!
I have quit a few times my job over some of the exact same points you mention. I hope this is not some vision telling me i will end up quilting 20 times !?!?
I can’t help but think that one reason why my learnings overlap so much with your points is I have been recently involved in creating an agnostic platform from scratch to build several projects, which rings similar to “starting new projects all the time, but also has to maintain a number of systems.” You are pressured into keeping things lean and focusing on engineer productivity. Otherwise you can’t easily bring in new people, nor can experienced people juggle multiple projects at once with minimal context switching. One day of onboarding for any newbie to take any change in several projects live, with the same confidence of a “git push” (literally, because we were doing gitops… Without knowing that’s what you call it :D)
Anyways, thanks for writing this. I’m framing it!
My baby is at https://github.com/rokmoln/support-firecloud btw but needs “productification”
“The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly”
I’m doing this all the time and I know at least one other developer doing the same :). It’s not related to amount of code, but how fast can someone solve problems and is building structures that allows do things faster and more performant.
Regarding juniors I have same opinion like someone else here in comments, juniors are more likely to repeat other’s opinions and do things like they read in tutorial, but didn’t battle test solution first.
I am retired after 35 years in the software trenches. Great list. #18 – ownership is particularly important, and drives many of the other areas. There was a reason that the developers of the original Macintosh computer (amazing things done by small groups of people) had their signatures embossed inside the case. Imagine if the splash screen that starts off a piece of software said “Created by: developers names” so the creators names (signatures) were a public part of the product. That simple thing would lead to better code! (Now I build musical instruments where every little thing is public. Immediately obvious how good that joint is.)
It’s so true, it really does all come back to people taking pride and ownership of their work.
You are absolutely right! 🙂
Thank you for this great article Justin
I’m intrigued by #19. What do you suppose are the values in interviewing a candidate? What would you pay attention to while interviewing a candidate? And how would you decide on casting a must-hire/maybe/veto vote?
A little about myself: I have around 10 years of experience working at small companies and startups; these companies and teams are lean and focused. I’ve been on both sides of table when it comes to interviewing and hiring.
On the hiring side, I agree that looking for certain signals seems futile, but I have a hard time finding or coming up with a better approach.
+1
Is there some other way to tell if someone will be a good team member before hiring or is it impossible?
1. Asshole filter
2. Relevant experience (or desire for)
3. Shared values
4. Communication skill level – careful to not let that be xenophobic, tho
Your points innovation & interviews stood out for me. Thank you for taking time to share your experience with us.
You’re welcome!
We need to venture more job opportunities in this sector and create a workable environment for the work..since the technology in computer is really taking us to another level in the coming years.
The “10x programmer” concept IS the “0.1x programmer” concept, just from a different baseline. The original studies where the idea came from were measuring the productivity spread between the best and the worst performers, not between the best and the average.
Fantastic article.
Whilst I agree with your opening statement about context being hugely important, I think the sheer volume of comments talking about how much this resonates shows you’ve hit on some fairly universal software advice.
My favourite point was on 0.1x vs 10x. It reminded me of the advice that up until a certain point you will win more tennis matches by stopping your own unforced errors than you will beating your opponent.
I feel like too many developers strive to reach this mythical 10x status without thinking about what small improvements could make them a better team member.
I love the tennis analogy, thank you!
Hey, this is an awesome list thankyou. As a 50 year old who still loves working as a senior developer, all of this resonated with me, you’ve really captured a lot of important points here succinctly. On your point 7, I’d recommend having a read of a fairly new book called Fundamentals of Software Architecture which has a great chapter about knowledge depth vs. knowledge breadth – in summary, as you get more experience and do more design level type work, you need to increase the breadth of your knowledge – to know what is possible and what is out there. At the same time you’ll find you can’t have a depth of knowledge about everything, otherwise you’ll run yourself ragged. You can still focus on a few different specialist areas or frameworks which you keep up to date with, but you need to supplement this with knowledge breadth – a shallow and wide knowledge about as much as possible.
Awesome article! Thank you very much!
I would like to add something to #6:
My experience is that you doing outstandingly well If you don’t pick the first solution that hops in your head for a problem. Instead taking your time to think about another solutions and compare them is a very economic act.
Agreed, that is something I struggled with early in my career, and sometimes still do when under time pressure.
wondering about the design of this site, why the comment is at the end of the page and why not just down below the post?
Thanks so much for the insight. This is really great 👍🏽
Point 9 really irks me about a lot of companies. I see it at my job and I hear about it from friends who also work in IT in varying capacities. In an industry that’s built on change, maximizing efficiency, and finding new ways to do things it astounds me that so many companies refuse to charge the way things get done.
I understand that some upgrades require massive restructuring that doesn’t always make practical or financial sense, but there’s just no excuse for certain things. No one questions why we’re still using this horribly buggy software from 1995, or why we haven’t automated a tedious but very simple manual process, or identified the source of a break in the process flow that confuses both the users and the devs who maintain the software. It’s maddening.
Great points overall.
nice
A big problem of modern software development that people continuously rewrite existing systems to use the new technologies. For example, I have iPad of the first generation, it is fully functional, however less than 20% sites still work on it. Sure, sites I developed still work great. I can’t say that new software offers something completely different, for example Gmail stopped working on the iPad as six months, although I didn’t notice any new functionality in it. When developer will focus on creation something really new, then just try new technologies for old things?
I am reading this on monday morning , there is so much to think about and take from. With that i am going to start my day.Thanks for writing this. HappyCoding.
The 10x engineer (or more) *absolutely* exists – that this is even for debate with someone with 20 years of seniority is concerning, to put it mildly.
Ever hear about dudes called Linus and Bjarne…? Ever hear about other guys that literally create their own OSes and game engines for fun…?
I agree at a high level, and I wrote a follow up post to address this exact point – https://www.simplethread.com/the-10x-programmer-myth/
This is a great article , a list i will keep in my bookmarks for long time.
Couple of things i would add from my 18 years of experience from firmware development to web apps development, and integrating very large and poorly written components and dealing with 100s of engineers on daily basis.
1- “Write code for others and do not own your code , write it so clean and easy to understand + review is so critically(publicly too) that people takes its ownership so easily without feeling any pressure from you. When you write for others to maintain then you become a developer who writes important parts of the system and pass to other people.
2- And finally a very important thing, “never get scared, software doesn’t bite, trying to write something complicated or something you have no idea about is the safest risk you would ever take in your life, it pays high dividends. The sooner you are fearless the faster you grow”
Thanks for tips
Great article as a software engineer over 10 years. I can feel every point.
Thank you.
This is something I should have read some 25 years ago. Excellent mate..
Some of the points are not just for Software Engineers, Eg. People don’t really want innovation.
I have shared with my son, who is a budding SE in his B Tech.
Thank you!
I posted your blog post on hacker news four days ago, there’s a lot of well deserved kudos for you also in the HN comment section https://news.ycombinator.com/item?id=28797485
Ps: just discovered right now that this blog post has a comment section 🙂 I use a comment blocker so often I miss this sections…
Me? 40 years.
My verbose review of your post:
Yup.
Ha! Thanks Don. 🙂
This year is 40 years of programming for me, as well, and I agree. This was an excellent list, probably the best of its kind I’ve seen.
Great list, thanks! Folks should also check out the work of Marty Cagan at the Silicon Valley Product Group (svpg.com). He has a lot to say about all this and has distilled his wisdom into a couple of excellent books too (“Inspired” and “Empowered”).
Agreed, Inspired is a great book! I haven’t had a chance to read Empowered yet.
Great article! Amazing points. I have 15+ years in development, I can relate (in some way) to every single point.
Regarding: “values engineer productivity over most other considerations”
One of the most ignored part of software development I have seen in projects is “maintainability”:
– Productivity of engineers are depending of the maintainability of the code.
– Maintainability of code depends on followings:
=> Are you able to run and troubleshoot your application code line by line? (Mostly inside code editor on local machine or on remote machine)
– People are adding more and more new services (sometime Heterogeneous service build with different languages/frameworks) and does not think about how difficult it will be to maintain it in future.
Really loved the intro – this is a very good point, very inspiring article – thank you!
Some great points.
Really like the first point about “I still don’t know very much”. I often feel bad about not knowing details about some of the areas too like BGP/Rust etc
But that’s the nature of our industry. There’s a huge amount of areas to dig into.
Always understand the business goals you’re setting out to achieve.
When I’m outlining a project, in a briefing or a requirements doc, I always start with the goal: “We need to email customers real-time tracking updates from USPS and UPS.” Or, “We want to find out which products are most frequently sold together.”
Making sure the business goal is clear right at the top helps reduce scope creep and dead ends. And if the stakeholders can’t agree on the business goal, well, you can’t even get started.
Another thought: there’s this gem from the Terry Pratchett novel Making Money, about the Igors (race of steampunk surgical/technological inventor geniuses), paraphrasing: “Igors didn’t build what you asked for. They built what you wanted.”
If you’re clear on the goals, you can build what’s wanted regardless of what’s asked for.
It’s hard to choose just one point, they’re all good. I’d roll with 2, 4 and 18.
#2: I just had a conversation with someone; the company built an incredible (and expensive) software product that then produced almost zero income. Why? As ingenuitive as the product was, decision makers had no need for it. Asking a client questions about what they want, we really do have to read between the lines to give them what they need. And I’ll second what George Tucker said about Igors – that was funny.
#4: Tech debt is a major topic – part of reducing it is avoiding it. I’ve seen some companies rewrite a product rather than maintain it. One lesson learned – figure out your assumptions and then question their validity.
#18: I had to laugh when I saw tautology. I thought the first sentence worked both grammatically (though debatable) and mathematically (definitely).
Just wanted to say thanks and give a big thumbs up. And extra thanks for the time it must have taken to put it together…that dedication to caring and trying to make the path easier for others speaks volumes.
I’m in the 25+ years experience camp, and found zero points of disagreement. There’s a ton of wisdom here–hard earned, I’m sure–and it’s something I wish had been required reading when I started. Very well done.
Thank you Chris! I greatly appreciate it!
I’m a new software engineer and love to read articles like this that offers practical wisdom in bite sized chunks. It makes it easier to digest.
Point number 6 stood out to me. Because of my lack of experience, I tend to overthink things which extends project deadlines, sometimes by a huge factor. I’ve been learning to just “cut shit” even if it feels like I’m making “mud pies” with my code. It sometimes helps just to get something working, and then think about how to improve it after. In most cases I end up iterating on the concept and producing something really great, which could only have happened by just starting.
Thanks for distilling your experience, it is so valuable for people like me just starting out.
Just the introduction part is valuable enough and even if the whole list was useless, it would have worth my time. I tried to pick which item is my “that’s it” one, but they are all so spot on that it’s impossible for me to favor one to others. Thank you for the brilliant article and kudos on your 20 years.
Pretty much full ACKN.
Guess I would only add
“Always maximize code for readability”
“Document your interfaces not the code”
“Don’t try to ride dead horses”
“RTFM i.e. documentation”
Verry good article, thanks!
Justin, your observations are spot on. Although I am enterprise architect, and in addition do some real hand-on hardware work with tube amplifiers, your lessons are universally true. I took the liberty to remind myself an referred your lessons in my own hobby blog on tube amplifiers (https://bespoketube.ismy.trade/wp/2021/11/23/software-engineering-lessons-applied-to-tube-amplifiers/)
Thank your for the lesson.
Just the introduction part is valuable enough and even if the whole list was useless, it would have worth my time. I tried to pick which item is my “that’s it” one, but they are all so spot on that it’s impossible for me to favor one to others. Thank you for the brilliant article and kudos on your 20 years.
Many thanks for the condensed experience of which many I could find myself in after more than 20 years of programming myself. I pretty much like the designer approach and call for simplicity. Team culture also is a big factor to success. Responsibility is another.
One I missed, to me always helpful was/is
“limit features in favor for stability and maintainability”.
Users don’t miss and cannot complain on features that are not existing. However, features that are out there available to the users must be solid, really solid. In addition, any features not existing don’t need to be maintained. This means cost savings on upgrades, customer support and time savings for focussing on the essentials.
In context, from an inner programmers view this means, less external libraries included can be more. Which is not meant to reinvent the wheel.
Maybe there is another one.
Standards are great, a working solution is even greater.
This is a great post with very solid and helpful insight. I would love to share it more widely across my organization. It would benefit so many.
I won’t do that.
1. It contains profanity, so I can’t risk sharing it in a corporate environment, without expecting repercussions.
2. I won’t plagiarize your work by editing it without credit.
3. I can’t in good conscious reference or credit your work due to issue number one.
Consider a few edits and you might change the world.
Fantastic article. I feel like too many developers strive to reach this mythical 10x status without thinking about what small improvements could make them a better team member.
Justin, thank you for sharing your experience. I’m still studying to get my first job in this field, but I re-read this article periodically to keep me in the right mind set. Thanks for helping me start off on the right foot.
Awesome article! I feel identified!
Thank you for sharing.
16. Software engineers should write regularly
Resonates well with me.
Writing helps gain clarity of thought. The best devs I came across are regular writers.
21. Never hide Errors/Exceptions – as they are your eyes and ears.
In 20 years, I came to love errors. Errors are the only way for me to know if what I built is actually working.
A good read.
Thank you!
I agree with most of the important points in this article. It is definitely worth a read if you’re interested in this topic. Delusion, the author, thanks for taking the time to share your knowledge.
Thanks for reading, Sakshi!
Thank you for writing this fantastic article. You have accurately described the way I feel after 10+ years designing and building software and have re-inspired me to keep learning even though I am very close to giving up the profession. Businesses and bosses need to read and understand this in order to better understand the role of software and developers in todays business environment.
This list is very adroit. I spent 1998-2014 at a keyboard writing code.
I feel like I could have written this list. These are the topics, that when properly addressed, make solid software.
In my view, there’s one big old problem: financiers. They pay. You do as they say. The people in finance will always destroy at least half of the goals in the above list, every. Single. Time.
So I quit programming. Why? Because I like doing the old-fashioned, blue-collar type job; whether I’m sweeping up saw dust or writing CAD software for UAV designers.
I’m allowed to do my best job on the pile of saw dust.
Programmers are NEVER allowed to do their best job.
Never.
I just want to take a minute to say Thank you for putting this out there. Your points are all extremely valid and valuable, and essentially timeless. And a good starting point for anybody who wants to reflect on his current project or job and see what he/she can improve. Enjoyed it immensely!
The 10x dev is the one that stops you from reinventing wheel. Or the one that tells you a project is doomed when it is.
The day you think you have produced a perfect software solution is the day you should consider changing your career.
Ive been is sw for the past 40 years; and if theres something Ive learned, then its that people you work with are the key to better software; and that software is like a wheel. If you build it square, it wont get you far.
I have about 13 years of experience myself and agree with everything here. Well put and concise, great work and thanks for sharing 🙂
Software developer with nearly 17 years professional experience. Thanks for posting! Enjoyed reading it! Well stated and not too verbose. Regarding #16, writing- I’m still mulling if I agree or disagree. Thank God, I have had a very successful career so far both as developer and later as as engineering manager and project tech-lead. However I don’t do too much writing and neither do people on my team (assuming emails don’t count). I started a few blogs over the years, but quickly abandoned them since they were time consuming. Between working hard and spending time with family, the only writing I end up doing is emails. We found that as code changes daily, and documentation does not- our documentation quickly got out of sync. Especially on tight time frames (and when are there not). Instead we opt to invest in making our code as clear and self-documenting as possible. Code review ended up nitpicking on the readability rather on the documentation. Any API used externally requires proper documentation of course- but everything else, not. Just my thoughts on that. Thanks again for posting, really made me stop and think!
Great post , Thank you for sharing.
Great post! I have learned something new and i agree on most of the points you wrote down! I also have a website in which i collected my philosophical utilities, if you want to give a check i’ll link my website here. I’ll constantly update them.
Spot on!!!
The biggest thing I’ve learned after 20 years of programming is that syntax and language features are the least important thing.
When you start out you’re intimidated by this foreign gobbledegook known as code. What could it all mean? You set your sights on being to understand it all… except by the time you do, you’ll realise how little value that has to your software output.
Now, don’t get me wrong, you DO need to know the syntax… but it’s nowhere near as important as understanding how to *structure* your code well. Poorly planned and architected code will cause you no end of issues down the road. You’ll end up needlessly refactoring and restructuring. Small changes will become huge challenges.
Nightmares are created through poor planning, and concrete ideas of how the future will be.
On the other hand, if you write your code using basic syntax, absolutely nothing bad will happen at all.
I value code structure (the WHAT) far more than the actual code doing the work (the HOW). You can easily refactor poorly optimised code, it’s far more difficult to go back to square one and fix bad architecture.
Honestly, I think there should be a programming course that STARTS with OOP, moves onto SOLID, and THEN worries about the syntax… lol
Thanks for sharing this.
I’m agree with the opinions point (#11).
When you explore different tools for same end result, later on you could make conscious selection based on project requirement instead of something else.
We need to ship the least amount of code, with high maintainability in mind, and choosing the “most well suited” tool is not possible without personal opinions.
Also journal point is true for me, it doesn’t matter if your written content will be read or not, the process of writing concept will improve your knowledge and your ability to have a solid overview of how every step of a certain process is related.
Similar to pseudo code.
Great post.
Thanks a lot for your article.
I agree with everything you have written, especially #7 and #12.
#7 is “If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system” and this is something which happens all the time. These days, I am not working as a software engineer anymore and I am at the policy level in Government. There, most systems are “designed” by committees of people with absolutely no experience or knowledge in software engineering. By “designing”, I mean defining the specs and coming up with the quality attributes which the system needs to have. And, of course, this results in (pretty much) impossible to implement systems.
Similarly, as I work at the policy level, I have noticed that “#12. People don’t really want innovation”. I agree that they are just looking at cheap wins and novelty and not having to adapt to a new (and simplified) way of working. People are perfectly happy doing the same thing over and over again. And I have also noticed that innovation experts are plentiful now (in the committees I referred to above) as you don’t really need to be an expert to call yourself an expert these days…
Thanks again.
Great article!
I started professional software development in 1995, and I agree with your points.
I had the same experience during my journey.
Thanks for sharing.
Lots of good thoughts here, based upon my 40+ years (programmer to cio and back).
My one addition: in a small team that 0.1x programmer is a worthy investment of your time. Your 10x programmer probably can’t do more, but getting your 0.1x up to speed can supercharge a small team of 5-10 people.
Search for “eagles” at pmtoolsthatwork dot com for more background.
It feels strangely good that nothing has really changed much in software. It means it’s a learnable foundational skill that doesn’t become obsolete even as everything seems to change.
Thank you *so much* for taking the time to write this and your other related articles (e.g., more about 10x…, your advice for bootcamp grads…, etc.) …Extremely helpful for this enthusiastic but humble newbie! …Feeling lots of gratitude for your time and perspective.
You were spot on in explaining how the user experience of certain codes is something that software engineers must consider carefully. Speaking of, some of the software in my office seems to be problematic lately. I guess it’s about time I call a technician to examine them.
Software engineering is a crucial discipline in the development of modern technology, ensuring that software is designed, developed, and maintained in a structured and efficient manner.
Hi there! I just wanted to drop a comment to say how much I’m enjoying your software development blog! As someone who is just starting out in the field, I find your articles to be incredibly informative and easy to follow. I particularly appreciate the way you break down complex topics into bite-sized pieces, making it easy for someone like me to understand. Your tutorials are clear and concise, and I always feel like I’ve learned something valuable after reading them And I read a similar blog on Go- Tech Solution , in which complete information about software development service is given, visit now!
Software engineers are essential to the modern world. Thanks Justin for taking time to share with the world your journey and challenges you faced and survived long 20 years in this industry. great job! Keep up the good work!
The valuable information about this that 20 years as a software engineer and the journey of life is really amazing. Thanks for the valuable information on this topic. Subscribed your blog.
Code evolves, and so should your skills. Embrace continuous learning to stay relevant.
Simplicity Is Key: Keep your code simple, maintainable, and easy to understand. Complexity often leads to problems.
Great post! I really appreciate the level of detail you’ve gone into about software engineering. Your experience really shines through in your writing and it’s clear that you have a deep understanding of the subject matter. Thank you for sharing your knowledge with us through this blog post.
Thank you for sharing. It is very interesting and helpful for students learning web design and development.
I found your post to be very informative and well-written. You have a real talent for explaining complex topics in a way that’s easy to understand.
Great find! This tool seems like a game-changer for collaborative coding. Being able to comment and discuss code without actually modifying it can streamline communication and enhance team collaboration. Looking forward to giving it a try! 👍 #Coding #Collaboration #TechTools
Wow, this is incredible! As someone who’s been in the field for about the same amount of time, I can completely relate to so many of these points. The part about coding standards being more important than coding language stood out to me. I’ve seen so many projects derailed because of poorly written code that’s difficult to maintain. Thank you for sharing your insights!
Nice Blog
Thanks for sharing this…
great blog post thanks for sharing this
Great article, thanks for sharing your thoughts.
I commented on some points on a different post: https://www.linkedin.com/pulse/commentary-20-things-ive-learned-my-years-federico-ricca-gmupf
Great blog post! I love how you broke down complex concepts into easy-to-understand sections. Your insights on the topic were enlightening and practical. Looking forward to more of your writing. Keep up the fantastic work! Please visit https://www.bandlab.com/luxuretvbuzz
“Really enjoyed this perspective.”
“Thank you for this valuable information. I appreciate the thorough research and thoughtful presentation. It’s clear you put a lot of effort into this.”
Thank you for sharing these insights! It’s inspiring to see how your experiences shaped your journey as a software engineer. I especially resonated with your point on continuous learning—it’s so crucial in this field. Looking forward to applying some of your lessons in my own career!
Wow, this is incredible! As someone who’s been in the field for about the same amount of time, I can completely relate to so many of these points.