Abdul Waheed’s Post

To my fellow software engineers! This a GREAT article that discusses the difference between being an "engineer" and being a "technician". This is the kind of subtle difference that can easily be missed until you give it a name. In short, it makes the following claims: Engineers, look for ways to automate repetitive manual labor. They continually seek out new problems to solve and take risks. Technicians, step in the place of automation. Redoing the same process over and over. Think, adding another parsing strategy to your ETL process. Being a technician can feel safe as the challenges and solutions are well known, but it's a false sense of security and it stifles growth. Be mindful of where you are in your career. If you are doing more technician tasks, try to protect yourself by taking on more risk and securing challenging work. https://lnkd.in/e3duXgfx

A lot of software engineers don't care enough about on-call when they're interviewing for a new job. On-call is one of the few items that can have a massive impact on your personal life, so you should understand what that impact will be before accepting an offer. Some questions I like to ask about on-call... 🔥 How often are you on-call? Anything more frequent than 25% of the time can be tough. 🔥 How long are you on-call for? Are rotations a week long? Anything longer and you can get bad on-call fatigue. But too short means you're on-call more often. 🔥 How many people are on-call at the same time? Is there a primary and a backup? 🔥 What's the expected response time to acknowledge the incident/page? 🔥 What's the expected time to be actively working the incident? That's not always the same as ack'ing. 🔥 Is the rotation 24/7 or something else, like business hours only or no weekends? 🔥 How many pages does the primary on-call get on average? What's a bad rotation look like? What's a good rotation look like? 🔥 What does the business hours work look like for the on-call? Or they doing toil tasks or still doing project work if there are no incidents? There's more to on-call than a lot of people think. And all of the answers to those above questions have a direct impact to your personal life! #softwareengineering #softwaredevelopment #sre #sitereliabilityengineering

Hi fellow #softwareengineers, here are some productivity #tips for you all. #SoftwareEngineering #ProductivityHacks #TechTips #techjobs #jobs #productivitytips #EfficiencyTips #TechProductivity #SoftwareDevelopment #CodeOptimization

What skills do you most value in a software engineer? ✏️ The 2 skills that are highly sought after are 1) IMAGINATION: It is quite difficult to deliver a product that satisfies the clients needs properly because there is typically a disconnect between what the client knows about their own business and their knowledge of the ways good software can help them. An engineer who can listen and build a complete picture of the clients needs, and then be creative in how they service those needs is a very valuable asset indeed. When those two bridges are successfully navigated, you end up with unique and highly functional software solutions that solve problems for the client that they may not have realized software could solve for them. 2) Well annotated work. It's inevitable that deadlines, family emergencies, general work items will lead to one programmer needing someone else to do some grunt work for them. High quality notes left in the code itself can save a lot of briefing time, meetings and downtime when other team members need to step in and help.

🤔 Ask any developer "What do you like most about your job?", and very often the answer is "I like solving problems." MadAppGang team’s no exception. We see problems and look for ways to solve them everywhere, including problems affecting productivity and speed 📌 Today we are sharing our experience with Site Reliability Engineering (SRE) — a useful tool for all developers. Find out what steps have helped us improve our product quality, increase deployment confidence, and reduce risk. Need help getting your project's development back on track? 🤙🏻 Get in touch #sre #developer #softwaredev

The T-Shaped Engineer https://buff.ly/3Sv8UG1 * Generalists have broad knowledge, specialists are deep in one area. * T-shaped engineers have both: broad knowledge and deep expertise. * T-shaped engineers are valuable because they can see the big picture, communicate effectively, and learn quickly. #softwareengineer #generalist #specialist #tshapedspecialist

I may not be writing some of the best posts but I like and comment on some of the best content on #testing #automation #softwareengineering Do check out the posts that I like and comment on, it will make you a better software engineer. I have found some of best software engineers here on this platform who drop in some gems every now and then.

Great software engineers automate repetitive/manual labor. Most large software engineering organizations incentivize anti-automation due to their desire for predictability. Predictable work is work that could have been automated but was not automated. The more predictable and routine a developer's job is, the more they tend to slide into becoming a technician. Teams that get into predictable flows are likely ignoring a promising opportunity for automation. https://lnkd.in/geaS98qC

One thing that helps me in my job is credibility. I am usually not comfortable with someone rubbishing my work either directly or indirectly, so I try to be really meticulous with my job. Something I have learnt about being meticulous is that in Software Engineering, I need to test my work. I need to do several negative tests on my work before it is moved to the testing team. This way, I am usually surprised if you tell me my code failed. I believe many Software Engineers should embrace this. No matter the rush, no matter how little the change is, you should test what you have done first if you want to avoid embarrassments. #Softwareengineering #Softwaredevelopment