https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/ Skip to content October's donation was made to the International Rescue Committee for Afghan Refugees. Simple Thread Primary Menu Close * Work * Process * Services * Our Story * Blog * Contact Us software development, thoughts 20 Things I've Learned in my 20 Years as a Software Engineer Justin EtheredgeJustin Etheredge Justin Etheredge / @JustinEtheredge / October 7, 2021October 7, 2021 Follow us on Twitter 20 Things I've Learned in my 20 Years as a Software Engineer20 Things I've Learned in my 20 Years as a Software Engineer Worried you'll miss us? Subscribe to get our articles and updates in your inbox. Email Address [ ] [ ] [Subscribe] 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... 1. has almost always been on small, lean teams where we have to do a lot with very little. 2. values working software over specific tools. 3. is starting new projects all the time, but also has to maintain a number of systems. 4. 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. Reach Out Comments (34) 1. [62bd26d][svg]Cristobal Gajardo Vera says: October 7, 2021 at 1:45 pm 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! Reply 2. [3b19026][svg]Dom says: October 7, 2021 at 5:39 pm 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. Reply 1. [Justin-][svg]Justin Etheredge says: October 7, 2021 at 6:06 pm Thank you Dom, I appreciate it! Reply 2. [37f5a2a][svg]Phil Kendall says: October 8, 2021 at 6:39 am 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 Reply 3. [1c0ac07][svg]Giovanny Quimbayo says: October 7, 2021 at 6:44 pm 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 Reply 1. [eee264b][svg]Joey DeFrancesco says: October 8, 2021 at 9:14 am 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. Reply 2. [ba2e109][svg]TheSleaze says: October 8, 2021 at 3:03 pm 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 Reply 4. [e6dd7b2][svg]Netherton says: October 8, 2021 at 6:34 am "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 :/ Reply 1. [153df32][svg]Jan says: October 8, 2021 at 7:43 am 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. Reply 2. [beb2193][svg]Anonymous says: October 8, 2021 at 12:01 pm 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. Reply 5. [bfd071d][svg]Makach Mouchkil says: October 8, 2021 at 6:36 am 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. Reply 6. [dfb3d63][svg]Gokhan Ercan says: October 8, 2021 at 7:01 am Perfect. I'm signing it Reply 7. [9369aa2][svg]Jan Gabriel says: October 8, 2021 at 7:28 am 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. Reply 8. [9eb8928][svg]Jeremie says: October 8, 2021 at 8:44 am 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! Reply 9. [5f9e960][svg]Alec says: October 8, 2021 at 9:20 am > 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. Reply 10. [4f46ac0][svg]Jason LaFerrera says: October 8, 2021 at 9:42 am What a fun treat to see your name on the byline! Hope you're doing well friend. Reply 1. [Justin-][svg]Justin Etheredge says: October 8, 2021 at 9:44 am Hey! Good to hear from you. Hope you're doing well! Reply 11. [1a3849a][svg]Anders says: October 8, 2021 at 9:47 am "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. Reply 12. [76814af][svg]V says: October 8, 2021 at 10:08 am 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! Reply 13. [76814af][svg]V says: October 8, 2021 at 10:27 am Oops, correction: not billions, sorry for getting carried away for a second there. It's actually just a few $100 millions Reply 14. [3304e19][svg]Jesus Jayaro says: October 8, 2021 at 10:48 am 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. Reply 15. [ac213fc][svg]Oakwoody says: October 8, 2021 at 10:55 am 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. Reply 16. [2e79e55][svg]A says: October 8, 2021 at 11:07 am 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. Reply 17. [ddd3de5][svg]John says: October 8, 2021 at 11:19 am 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'. Reply 18. [67fa0e3][svg]AW says: October 8, 2021 at 11:29 am "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. Reply 19. [be27ce8][svg]SangD says: October 8, 2021 at 11:42 am Very well written points. I like all of these. I went through many of these and I understand how it feels. Thank you. Reply 20. [3b33e5c][svg]MGBielski says: October 8, 2021 at 11:48 am 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. Reply 21. [167c67c][svg]Tim says: October 8, 2021 at 11:54 am 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 Reply 22. [ace60ec][svg]Sam says: October 8, 2021 at 12:39 pm 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. Reply 23. [fa0ad79][svg]Roy says: October 8, 2021 at 1:28 pm 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? Reply 24. [a990f5b][svg]Andrei Neculau says: October 8, 2021 at 2:22 pm 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" Reply 25. [1137160][svg]qqqq says: October 8, 2021 at 2:30 pm "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. Reply 26. [1b729b8][svg]Jonathan Dale says: October 8, 2021 at 3:04 pm 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.) Reply 27. [6fa47c8][svg]Andrzej says: October 8, 2021 at 5:18 pm You are absolutely right! Reply Leave a comment Leave a Reply Cancel reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment[ ] Name * [ ] Email * [ ] Website [ ] [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] Leave a comment More Insights View All * product management, thoughts Celebrating Google's Birthday and Former Products Another candle on the cake makes us reminisce about products from days gone by Brian BassetBrian Basset Brian Bassett / @brian_bassett * software development, sql Secret PostgreSQL Trick Nick AglianoNick Agliano Nick Agliano / @nickagliano * agile, product management, software development Agile Principles: Welcome Change Al TenhundfeldAl Tenhundfeld Al Tenhundfeld / @alric Reach Out We're here to help. Tell us a bit about your project or idea and we can help you figure out your next steps. * Your Email* [ ] * Tell us about your project or idea* [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] * Comments [ ] This field is for validation purposes and should be left unchanged. [Send] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] Simple Thread 2400 Old Brick Rd, Suite 336 Glen Allen, VA 23060 1.877.893.5486 Read Our Whitepaper Bootstrapping a Digital Product * hello@simplethread.com * Careers * Privacy * + + + + + Proudly based in Richmond and Charlottesville, VA. (c) 2021 Simple Thread, LLC.