Career Development Resources

DZone's Featured Career Development Resources

Four Ways for Developers To Limit Liability as Software Liability Laws Seem Poised for Change

By Philip Piletic CORE

For many years, the idea of liability for defects in software code fell into a gray area. You can find debate about the topic going back and forth since at least the early 1990s. Throughout, software developers argued that they shouldn't be held liable for coding flaws that are both difficult to detect and sometimes even harder to fix. And in any case, knowingly exploiting software defects for nefarious purposes is a crime already — so shouldn't cyber criminals alone bear the responsibility for their actions? As a result of these arguments, there haven't been any serious attempts to pass legislation making developers liable for flaws in their code. And for even more ironclad protection, most software developers also include liability waivers in their EULAs. However, there's reason to believe that the winds surrounding this issue are beginning to shift. As a result of high-level policy reviews originating in the White House, multiple federal agencies, including the NSA, FBI, and CISA, are now calling for developers to develop workflows that make their software products secure by design and by default. And if that's the stance the US's top law enforcement agencies are going to take from now on, it's reasonable to assume that some kind of regulatory or statutory changes to that effect may soon follow. The mere suggestion of such changes, however, should be enough to spur the most sensible software developers into taking action. The good news is that it shouldn't be difficult for most to cover their bases with respect to software liability. To get them started, here are four steps developers can take right now to guard against potential changes to software liability laws. Build Security Checks Into Software Pipelines The first thing to do to head off software liability concerns is to create security checkpoints throughout your development processes. This should begin with thorough code review and certification processes for all repurposed code. This is essential since most software developers now rely on reused open-source code or on self-created code libraries that speed up the development of new software. But as the recent Log4j security incident demonstrated, reused code can introduce vulnerabilities into new software that come back to haunt you. So, it's a good idea to formalize a process whereby you can attest to the security of all reused code — both internally developed and otherwise — before it makes it into production software. Then, it's a good idea to make extensive use of source code security analyzers throughout the development process. This can make it more likely to identify security issues early on while they're still relatively easy to fix. It can also serve as evidence of your efforts at secure code development, should questions arise after a finished product release. Commit to 3rd-Party Pre-Release Code Security Audits The next thing to do to guard against potential software liability concerns is to commit to having all software products go through a 3rd-party code security audit prior to release. This provides yet another opportunity to fix security flaws before they can cause liability issues. Plus, it guarantees that an expert, neutral set of eyes goes over your work before it ships. That can help to combat the kind of vulnerability blindness that often afflicts development teams who become accustomed to reviewing their own work. It can also reassure customers that no efforts were spared to put their security front and center in the development process. Provide Adequate Customer Support In recognition of the fact that no software is ever bulletproof, it's a good idea to develop a plan to support customers in the event they're affected by a security issue in one of your software products. For business customers, this might extend to providing direct and/or contracted technical support to aid recovery efforts after a security incident. Of course, you can only take such efforts so far due to the costs involved, but being there for an affected customer could head off any attempts to hold you liable. For individual customers, it's also smart to partner with an identity protection firm to have them ready to assist if your software suffers a security issue that might lead to identity theft. According to Hari Ravichandran, CEO of Aura, "Competent identity fraud prevention can be an inexpensive way to prevent users from suffering financial losses in the first place. It's a great way to limit liability in the aftermath of a software or data breach." Purchase the Right Liability Insurance Even if you go to great lengths to find and fix every bug and potential security flaw, it's always possible for something to go overlooked. As a result, it's a good idea to come up with a liability risk management plan that includes proper insurance coverage. This is essential because, although there aren't any specific laws or regulations making software developers liable for losses stemming from the use of their products, general product liability laws can and do get applied to developers on occasion. The good news is that the preceding secure code development practices should go a long way to proving good faith in any potential liability case. However, there's no way to eliminate the risk of losses stemming from even a frivolous lawsuit. Therefore, to protect yourself, it's a good idea to carry errors and omissions (E&O) insurance and a general product liability insurance policy at the very least. The Takeaway The bottom line is that it's just a good idea for software developers to get their code security ducks in a row now to prepare for any coming shifts in software liability law. Plus, they should develop plans to deal with the aftermath of a security event involving their software now. That way, whether there's any change to the existing liability status quo or not, they'll be ready to handle any potential outcome. More

Slowing Down the Release Cycle

By Tamás Balog

I’ve been working in IT in various roles for more than 12 years, and I witnessed and experienced how release cycles became faster and faster over time. Seeing recent (and not so recent) trends in competitiveness, degradation of attention span, advertisement of short-term satisfaction, etc., I wonder where this increase in speed will lead in terms of software quality, end-user experience and satisfaction, engineer burnout, and whether it is possible to slow down a little. What Do We Want? Anything! When Do We Want It? Yesterday! Two things come to my mind regarding this topic: shortened attention span and the want for short-term perceived satisfaction. I hear people complain about a shortened attention span, which is due to many various factors like social media (see products like TikTok, YouTube Shorts, and many others), and I feel as if more and more products pop up that promote and worsen this. At the same time, I also see people wanting and promoting short-term or immediate satisfaction, be it anything really. With online purchases, same-day shipping, online trading, 30-40 year mortgages to get that house now, and more, people nowadays want everything, and they want it yesterday. Long-term planning and long-term satisfaction are becoming less of a thing, and that is, to a degree, mirrored by the IT sector as well. Drawing a parallel with software releases: nowadays, continuous delivery and deployment are very prominent along with containerization, and with all that automation, production deployments can happen every hour, every 30 minutes, or even less. Although it is definitely a good thing for deploying bug fixes or security fixes, I wonder how much benefit it really has when it comes to deploying features and feature improvements. Is the new code deployed actually benefit your end-users (whether it's for competing with another company or not), benefit the company's engineers for improving/laying the foundation for further development (I see no problem with this), or is it just due to a perceived/false urgency coming from higher-ups, or from the general state of the current digital market, to "compete" with others. Does One Actually Know What They Want? In childhood, we are taught (ideally) that we don't necessarily get everything we want, and not necessarily when we want it, but we have to work hard for many things, and the results and success will materialize sometime in the future, and as periodic little successes along the way. I separate wants into two categories: whether your customers know what they want and whether you or your company know what your customers want. As for the earlier: when your customers are satisfied with your product, that is awesome. But when you always give them everything they want, and/or immediately, you might end up with cases like this: it is a problem that a certain video game is not released in time, but it is also a problem if released in time due to pressure, with questionable quality. So, they don't even necessarily know what they want. (If you are a Hungarian reader, you might be familiar with the song called Az a baj from Bëlga). As for the latter, at least in the world of outsourcing, though, there is a distinction: the client pays you for delivering what they want to their customers, but your children don't. Clients might leave like an offended child (and might never come back) if they don't get what they want when they want it, even if that thing is unrealistic or, even more, not so legal. But that is something that can be shaped by great managers, Project Owners, Business Analysts, etc. On the Topic of Analytics It is one thing that end-users, like when in a candy store, don't necessarily know what they want. But do companies themselves actually know what their customers want, or do they just throw things at the wall, hoping that something would stick? Companies can get their hands on so much analytics data that it's not an easy feat to process it, organize it, and actually do something with it. If companies don't have the (right) people, or they burn out and leave, they would have no proper clue of what their customers want and in what way. This isn't helped by the fact that, in some cases, there may be a large amount of inconclusive or contradictory information on how certain features are received by customers. Take, for example, one of my previous projects: there were several hundreds of active multi-variant tests running on the site, in many cases with 5, 6, or more variants, at the same time, along with tens of active SiteSpect tests in the same area. How you draw conclusive results from them regarding customer conversion rate and what works for your users is magic to me. These all can result in potentially premature decision-making and can lead to uncertainty. What About Slowing Down? It may be a good idea to consider taking a step back, getting some perspective on how your project operates, and slowing down the release cadence a little. Whether it is better care for your customers and your project members, or you just want the project to get more money from users, releasing less frequently may be a good idea... if you can reallocate time, money, and effort properly. I know slowing down the release cadence is not applicable to all domains and projects, and it might be suitable differently for small, big, open-source, greenfield, startup, commercial, etc. type projects. But the option is still there, and it doesn't hurt to think about its potential benefits. A Personal Example I personally develop plugins for JetBrains IDEs, and I like to bulk-release new features and improvements. It gives me more time and headspace to come up with ideas to further polish features so users can also get a better version of them right away instead of getting them in chunks. This also produces less technical-/feature-debt for me and less paperwork, e.g., for tracking and maintaining issues on GitHub. It also saves me time because I have to go through the release process less frequently. I produce fewer release-related artifacts over time compared to, for example, releasing each new feature individually. And it produces fewer plugin update cycles for IDE users as well. However, when it comes to important or critical bug fixes, I do release them quickly. Question Time I know it can work quite differently for companies with hundreds of engineers finishing features and code changes each day and wanting to release those features in the wild soon after they have finished. But, even in that case, it might be a good idea to slow down a bit. It kind of reminds me of publishing music: you can either drop a hit single now and then and then later wrap it and call it an "album," or you can work on a bigger theme for a while and publish them at once as a real album. I also realize in regulated domains, frequent and fast releases are required to keep up with regulations and legal matters. (I still remember when the cookie policy and GDPR had dropped.) Now, let me pose a few questions you might want to explore deeper: What if you would release less frequently? Do you need a release every minute/hour/day? Would a one-week/two-week/one-month/... cadence be better suited for your project? Would it make sense for your domain and project? Do you actually have the option to do so? What advantages and disadvantages would it have on your engineering and testing teams' mental health? Would they feel more ownership of the features they develop? If you have manual testing for each release, would less frequent releases have a positive effect on your testing team? Would they have more time to focus on less tedious tasks? Would they have more time to migrate manual test cases to automated ones? What effect would it have on your end-users/customers' satisfaction? On your customers' conversion rate? On your infrastructure and code/feature quality? On your business in terms of customer retention, income, and growth? If you are in a cloud infrastructure, would less frequent deployments lower the costs of operation? Let me also get a little deeper into two specific items from this list that I have had experience with before. Feeling Ownership of the Product I'm sure you've been in a situation, or at least heard someone, after finishing a bigger feature, say something like, "We could also do this and this!", "We should also add this!" and their variations. When you don't have the time to enjoy what you've accomplished, and you are instantly thinking about the next steps, it's difficult to feel ownership of the feature you've just finished. If engineers had the option to work longer on a feature and release it in a better state in fewer releases, I think that feeling of ownership and accomplishment could become stronger. (Unless you cannot relate to the feature or the whole domain at all for any reason.) On a related note, I recommend you watch the YouTube video called Running a Marathon, one mile every hour from Beau Miles, from which my favorite quote is, "Been meaning to do this for two years. 10-minute job." Manual Release Regression Years ago, I was on a project in the hotel accommodation domain, on which the website we developed was also used as a platform so other companies could pay our project's company to create branded websites for them. The creation and configuration of these sites were handled by a dedicated team, but testing affected many other teams. Almost every two weeks, we received an email from that team asking us if we would be kind enough to "do a slight regression" (automated and manual) in our area on those (up to ~20) new branded sites and/or points of sale. I know that the site creation was an on-demand process, and it was necessary to serve those customers quickly. That is fine. However, many people would have benefited if those manual regressions occurred, e.g., only once in a month instead of bi-weekly. Even with a bigger scope and workload, it would have required less effort from our team (context switching, reorganizing sprint activities, communication overhead, etc.), especially since there wasn't always a heads-up about when we would have had to do it. Thus, not much planning could have happened beforehand. Closing Thoughts There could have been many more aspects mentioned and taken into account, but covering every aspect of this topic was not the intention of this article. Hopefully, you leave with some of these questions and ideas, making you think about how to answer them or apply them to your projects. This article came to life with the help of Zoltán Limpek. I appreciate your feedback and help. More

Mastering React: Common Interview Questions and Answers

By Atul Naithani

How To Start a Successful Career in DevOps

By Mariusz Michalowski

Navigating Resistance To Change in Digital Transformation: Insights for CIO Strategies

By Deepak Gupta

Best Platform To Learn Full-Stack Web Development

Are you aspiring to become a proficient full-stack web developer and wondering where to start your journey in 2023? With the ever-evolving landscape of technology, choosing the right platform for learning is crucial to gaining the skills and knowledge you need to succeed. In this article, we'll explore the best platforms that offer comprehensive full-stack web development courses, equipping you with the tools you need to excel in this dynamic field. Web development continues to be a highly sought-after skill, and full-stack developers are in great demand. These developers possess the ability to work on both the front-end and back-end aspects of web applications, making them versatile assets for any tech team. If you're looking to acquire these skills, choosing the right learning platform is key to your success. What Is Full-Stack Web Development? Full-stack web development involves working on both the client-facing front-end of a website and the server-side back-end that powers it. This means handling everything from designing user interfaces to managing databases and server configurations. Mastering full-stack development requires proficiency in multiple programming languages, frameworks, and tools. Learning Full-Stack Development Learning full-stack web development opens up a world of opportunities. It allows you to create entire web applications from start to finish, giving you greater control over the development process. This knowledge is highly valued by employers, as it demonstrates your ability to work across the entire technology stack. Key Components of Full-Stack Web Development Front-End Development Front-end development focuses on the user interface and the visual elements of a website. Proficiency in HTML, CSS, and JavaScript is essential, as these technologies are used to create responsive and engaging user experiences. Back-End Development Back-end development involves creating the server-side logic that powers a website. This includes handling data, security, and user authentication. Popular back-end languages include Python, Ruby, PHP, and Node.js. Databases and Storage Understanding databases is crucial for storing and managing application data. Learning database technologies like SQL and NoSQL is essential for creating efficient and scalable web applications. Version Control and Deployment Version control tools like Git enable developers to collaborate on projects seamlessly. Additionally, learning deployment strategies ensure that your applications are accessible to users. Factors To Consider When Choosing a Learning Platform With numerous platforms available, here are some important factors to consider before making your choice: Course Content Ensure the platform offers a comprehensive curriculum covering both front-end and back-end technologies. Learning Flexibility Look for platforms that offer flexible learning options, allowing you to balance your studies with other commitments. Real-World Projects Practical projects are essential for applying your knowledge to real scenarios and building a strong portfolio. Instructor Quality Knowledgeable instructors can make a significant difference in your learning experience. Student Reviews and Success Stories Research student reviews and success stories to gauge the platform's effectiveness in producing skilled developers. Platform A: Comprehensive Curriculum and Industry Connections Platform A offers an extensive curriculum that covers the latest technologies. With industry connections, they provide opportunities for networking and internships. Platform B: Interactive Learning and Hands-On Practice Platform B focuses on interactive learning through coding challenges and projects. Their hands-on approach accelerates the learning process. Platform C: Self-Paced Learning and Personalized Feedback Platform C caters to self-paced learners and provides personalized feedback on projects. This flexibility suits those with busy schedules. Platform D: Bootcamp Style Intensive Training Platform D offers boot camp-style training, delivering intensive and immersive learning experiences within a short timeframe. How To Get Started On Your Full-Stack Learning Journey To embark on your full-stack learning journey, follow these steps: Choose a Platform: Select the platform that aligns with your learning preferences and goals. Set a Schedule: Allocate dedicated time for learning each day or week. Practice Regularly: Consistent practice is key to mastering the concepts. Build Projects: Apply your learning by working on real-world projects. Seek Help: Don't hesitate to ask questions or seek help from online communities. Benefits of Mastering Full-Stack Web Development Becoming a proficient full-stack developer offers several benefits: Versatility in the job market Enhanced problem-solving skills Ability to create entire applications independently Collaboration potential with different teams Overcoming Common Challenges in the Learning Process Learning full-stack development can be challenging. Here are some tips to overcome common hurdles: Break down complex concepts into manageable parts. Join coding communities for support and guidance. Don't fear failure; it's an essential part of the learning journey. Conclusion The demand for skilled full-stack web developers continues to grow. Choosing the right learning platform is your first step toward mastering this valuable skill set. Whether you prefer a comprehensive curriculum, interactive learning, self-paced flexibility, or an intensive boot camp experience, there's a platform tailored to your needs. Embrace the journey, stay persistent, and watch yourself evolve into a proficient full-stack developer.

By Masudul Herry

Five Free AI Tools for Programmers to 10X Their Productivity

Artificial intelligence has proliferated across industries and sectors. Be it education, astrology, food and beverages, engineering, or medicine — AI applications are found in all and sundry. Software engineers, programmers, and developers can utilize Artificial Intelligence tools to 10X their productivity with enhanced efficiency. Writing code is an exciting yet tedious job. With the help of AI tools, error-less secured codes can be written fast. AI is here to make the life of our computer programmers conveniently easier with the below-mentioned five free AI tools. What Are AI Tools in Programming or Coding? AI coding tools act as assistants and assist programmers and developers in writing error-free and accurate codes. They are also efficient at completing codes with initial prompts and providing suggestions in real time for betterment. Qualities of an AI tool Amazon CodeWhisperer The coding companion, the Amazon CodeWhisperer, helps developers build applications faster with extreme security. More than a billion lines of code have been used to train CodeWhisperer which enables it to garner a wide range of intelligent code suggestions in real-time. Be it snippets or completely functional functions based on your prompts or pre-existing codes — CodeWhisperer helps developers avoid tedious and time-consuming coding jobs, eventually expediting the building of APIs. ChatGPT The most popular AI content generation tool that helps in content moderation as well. ChatGPT intriguingly writes amazing codes. The only know-how you need while using ChatGPT to make optimum utilization is the art of writing prompts. CodeGeeX This is your AI-based assistant that completes your coding tasks before you can imagine. Powered with the pre-training of 20+ programming languages, trained on 850+ billion tokens on a cluster of 1,536 Ascend 910 AI Processors, with 13 billion parameters. CodeGeeX offers Multilingual code generation, Crosslingua translation, Customizable programming, and Open-source and Cross-platform task completion. GitHub Copilot One of the most popular and widely adopted AI developer tools, GitHub Copilot has been trained on billions of lines of code. It transforms natural language prompts into coding suggestions in more than 12 languages. Bugasura AI-powered bug-tracking tool that streamlines the tedious bug management process seamlessly. The ability to automatically detect bugs and provide insightful pattern detection assists Bugasura in monitoring and controlling bugs. Also, it provides detailed analysis for better bug tracking for the future. It mitigates bugs as per the severity and tags each bug found with a relevant description. It offers a single platform where you can connect, write about each bug, and discuss for future prevention. Is It Possible To Develop Codes Even if You Have Negligible Knowledge of Coding? Well, if this question had been asked two years back, the answer would have been no. However, with the emergence of flawless AI tools that have been trained with accurate and error-free data, today, anyone can write codes. The use of machine learning algorithms enables these AI tools to generate code as per the asked-for user functionalities and specifications. Does That Mean Efficient Does Will Lose Their Job? The answer is no! AI is not here to take the job of coders or developers but to make coding easier for them. The thought of AI replacing humans in totality is a far-sighted cry and it is not going to happen. Remember, AI cannot use itself. Humans will use AI. Read this Dzone article to clear up this confusion. Wrapping It Up Simply put, AI tools for programming are a boon for developers as they help them complete their coding tasks quickly and with precision. There are many AI tools for programming available, and five of the most popular ones have been mentioned here. The advent of AI tools has simplified coding, and anyone with minimum or negligible know-how can write code.

By Mirza Arique Alam

Me, a Conference Speaker? Yes, You!

I have been in your shoes: it is very intimidating to get in front of strangers and speak about your passion: technical topics where others are stronger; opinions that are the antithesis of commonly-held beliefs; real-life solutions which you don’t believe are that unique. Or perhaps the most scary: people get bored and walk out on you. Yet, how many conference sessions have you attended or watched webinars where you thought I knew this, I know more than the speaker, or even I totally disagree, and here’s why. The speakers you enjoy listening to — the David Belvins, Holly Cummings, Trisha Gee, Josh Long, Reza Rahman, Venkat Subramaniam of the world, and many others — started simply: likely pushed, goaded, and mentored into speaking. Practice and experience — and likely multiple failures — help novice speakers into rock stars. Admittedly, I am not a regular conference speaker, having spoken only a handful of times at JavaOne, Devoxx UK, DubJug, plus some local JUGs. I do, however, review submissions for conferences and have thoughts on what may (or may not) make for a good session. My Lucky Break How did I become a submission reviewer: by speaking up. JavaOne 2012 was not a year for stellar content, at least in the sessions I attended. While it’s not reasonable to expect every session to knock your socks off, in 2012, the sessions were almost uniformly bad: repeats from previous years, no earth-shattering news from Oracle, and advanced sessions that weren’t. A former co-worker on the flight home totally agreed; both of us were very disappointed and frustrated. A purported advanced talk on Groovy is my personal bellwether of what a talk shouldn’t be: the presenter opened up his text editor and basically said So. what do you want to see? No agenda. No topics. No goals. No preparation. Just a blank editor (no IDE) in which to write code...and when he missed multiple syntax errors in his initial Hello World, I walked out. After reflecting on my experiences, I reached out to Stephen Chin — then an Oracle Technology Evangelist for Java and heavily involved with JavaOne — to offer (hopefully) constructive criticisms: identifying four particularly-bad sessions and identifying ways sessions could have been improved (salvaged) — Stephen’s response: inviting me to participate in the JavaOne 2013 review process. I no longer review submissions for Oracle but currently review for Devoxx UK, which I thoroughly enjoy. Identifying Potential Topics With technology conferences, almost anything is a potential subject. Everyone’s backgrounds and experiences are different, and everyone has their story to share. The constantly-changing landscape leads to a plethora of ideas on ways to use and incorporate technology, and this diversity encourages us to want more: every day, you (hopefully) learn something new. It’s possible that you’re not even aware of what you’ve achieved: diving deep into Kafka to improve your organization’s analytics; introducing Neo4J to represent relationship graphs better than in a relational database; designing a comprehensive infrastructure-as-code approach for cloud deployment; using observability tools to better understand production problems. What you offer is the knowledge that others take home to improve their work. Ideas that appeared unrealistic now seem possible. It’s more anonymous than talking with peers and friends but just as valuable. You’d be wrong to believe that technical conferences only want in-depth technical sessions. Admittedly technology deep-dives get the buzz and excitement, but it’s not exclusive: UI/UX, imposter syndrome, careers in technology, and mental health are topics presented in recent years — different focus, but interesting and useful. When I review, I look for talks with real-life experiences, sharing problems — both expected and unexpected — and seeing possible solutions. Elle Waters' Devoxx UK 2018 talk Accessibility for UX: Don’t Worry, It’s Much Worse Than You Think started with her story of proudly showing her father an application intended to assist the elderly in managing their medications which he — the target audience — found extremely hard to use. Fascinating talk with an engaging speaker, and it really opened up my eyes. Totally blown away; probably the top session I attended that year. You might not have something as life-changing to share, but you do have something to share. A particular passion, technical or otherwise? A work success you’re particularly proud of? Your personal journey from music composition to software engineering? How about a one-line commit — based on months of research — that improved overall performance by 50% (true story IKYN)? Technology has an infinite number of facets and therefore an infinite number of stories to tell. So, what story can you share with others? Writing up Your First Submission Besides the obvious (e.g., you won’t be asked to talk until you actually submit), the submission shows both structure and goals of whatever you want to talk about: it’s not enough to state, Let’s talk about the impact of microservices on data quality if you can’t explain why that’s important. [And IMO it’s also not enough to say I’m a Java Rock Star; trust me. JavaOne had multiple submissions chosen strictly from past reputation which ultimately failed.] To help understand what a typical submission looks like, I’ll use my Devoxx Morocco submission to explain the different sections. All Devoxx conferences use the same app (and a great app at that!); other conference will ask for similar but not necessarily identical information, but hopefully, this gives you the basic concept. Title: Intriguing or interesting enough to attract the reviewer’s attention and get her/him to continue reading. Tags: After Track (#4) helps to further categorize the submission, e.g., AOT, IOT, Cloud, Microservices, Java, Scaling, Garbage Collection, whatever. Description: What attendees read to decide the sessions to attend, your main (only?) opportunity to grab their interest and, hopefully, get them to attend. Key point: what do attendees walk away with? Track: Top-level grouping, Devoxx Morocco subdivides their sessions into Architecture, Security, Data and AI, Devops & Cloud, Development Practices, People and Culture, Programming Languages, and Ui & UX sessions. Session Type: IMO, session types are more about the length than the actual type of talk, based on your available content or comfort level; new presenters often want a shorter slot. Elevator Pitch: Your sales pitch to reviewers, a quick attention-grab to get them to spend time digging deeper into your submission (reviewing slides or watching videos takes time). Notes: Notes are the most important tool in allowing reviewers to better understand a submission’s purpose, goals, topics, and organization that the submitter hopes to achieve. Slides link: Slides, blog posts, GitHub repos, whatever provides backing information; you may create prototype slides for a new talk or use material from an internal work presentation to better show what you intend to talk about. Video Link: Usually the most challenging for new(-ish) presenters. Devoxx UK asked me to record a trial presentation for my first submission, which I did with work peers. In the future, you’ll have recordings from other conferences, which is helpful even if the talk is totally new. My Red Flags Previous experiences help to identify submissions that require a dose of skepticism. This doesn’t guarantee immediate rejection, but does require more effort when reviewing: who is the submitter, what is her/his background, has s/he posted on this topic, are there other submissions that are stronger, does the topic/subject stand on its own? Everything: The Let me tell you everything about X submissions are usually either too general or unfocused (or both), and similar posts are often available online. Live Coding: Do you attend conferences for group Pair Programming sessions as a result of the presenter not finding their syntax/logic errors? I don’t. I’ve witnessed too many fiascos and don’t trust them (aside from Tricia Gee and Simon Maple, who proved themselves to be masters). Multiples I: Multiple submissions from single submitter of identical content, either in multiple tracks or of different session types. It may be that the submitter is unsure of her/his content, which may be resolved by working with the submitter, or that the submitter is fishing for an acceptance. Multiples II: A large number of submissions from a vendor attempting to raise their technology’s visibility, usually hoping that something resonates with the reviewers. Requires effort to sort through the different submissions to find something appropriate for the conference. Numbers: often of the 50 x in 50 minutes form: kitschy, buzzwordy, general interest, and rushed, rarely leaving time for Q&A. Vendors: Contentious among reviewers: is it a vendor explaining best practices for solving common problems or a blatant product push? I prefer submissions from those who use the technology as a client of the vendor rather than the vendor itself, but not always possible. Weird/Inappropriate: Topics or subjects that divide people are not appropriate for conferences, such as a submission (roughly) entitled Introducing Religion Into Secular Software Engineering. Universally down-voted. And If You're Not Ready? Other options exist if presenting at big-time conferences is too big a leap, and you want to start small, such as presenting at work or local user groups. These groups are often smaller, and you may feel more comfortable among acquaintances. Another possibility is conference labs, where you can help others come up to speed more quickly on a specific technology, protocol, or approach. Again, many possibilities exist, from authenticating using OIDC to making Pepper the Robot walk and talk. Labs tend to require more preparation, which may explain why not many are submitted (especially in recent years). Closing So, how soon are you going to submit your talk? Take the leap, It’s personally rewarding and professionally beneficial, and you may even surprise yourself.

By Scott Sosna CORE

Are You an Efficient Developer? Then AI Is After Your Job

In my previous post, I wrote about finding your competitive advantage as a software developer in a world of encroaching AI. I believe there are a few questions more relevant in the coming decade, so I like to elaborate on the topic in this and my next postings. You can only maintain such a competitive advantage if you focus on tasks that humans by their very nature can do better than machines. There are two necessary properties of software development that illustrate and coincide with the relative strengths and weaknesses of humans versus computers They are efficiency and effectiveness, and will be the focus of today’s post. I give credit to Uwe Friedrichsen for pointing out this distinction in a recent blog. Chess and Submarines Who would be among the most esteemed persons alive, in science, art, and sports? A poll taken in 1985 might include physicist Richard Feynman, actor Meryl Streep, philosopher Susan Sontag, and probably also Gary Kasparov, the young Russian chess grandmaster and new world champion. Several years before, you could already practice chess against a variety of digital opponents. The algorithms in these toy devices must seem unsophisticated now, and their feeble computational horsepower laughable. But an early AI they certainly were, even when they were no match for serious human players, least of all a grandmaster. Moore’s Law quickly took care of that. In little over a decade (1997) the same world champion lost against IBM’s Deep Blue team. This 25-year-old defeat of man against machine did not make us unduly worried that AI would soon take over in some Terminator-like dystopia. If anything, it confirmed that chess is hard for humans and easy for computers. “The question of whether a computer can think is no more interesting than the question of whether a submarine can swim," according to Professor Dijkstra. True, you cannot compare a computer winning at chess with the way Magnus Carlson does it. The way a nuclear submarine displaces water is equally incomparable to how a shark does it. Machine intelligence, whatever way you define it, is only externally analogous to what goes in a human brain. It’s the effect that counts. Yet, I disagree with the suggestion that the question of a thinking computer is uninteresting. The Journey and the Destination According to the Longman dictionary, effectiveness is the fact of producing the result that is wanted or intended; the fact of producing a successful result. Checkmate is such a successful result. Efficiency is the quality of doing something well with no waste of time or money. Of the infinite number of possible matches, fool’s mate is the most efficient one. Apropos: note the purely economic thinking in the definition. Only a “waste of time or money” is considered. Had energy been a factor, no human invention would be efficient compared to its biological counterparts in terms of raw energy consumption. Once the computer can do a job effectively as well as efficiently, humans have made themselves redundant from a cold economic perspective. You’re welcome to dabble for your own enjoyment but don’t expect a paycheck. People still enjoy chess because it was never a means of survival. We don’t need it to grow food or build houses and only a small elite of the best players make money from it. Had chess been a production resource (like land and labor), human chess players would have no competitive advantage. Being effective means arriving at a satisfactory result. We either have it, or we don’t. You can exceed expectations, or fail miserably to any degree, but it’s the binary thumbs-up or thumbs-down that counts. Efficiency is about how you perform the constituent tasks. It’s a quality that allows more leeway. Parts of the process can be less optimal than others and still contribute to an effective result. Other terms that coincide with the dichotomy are the what (and why) versus the how. It’s doing the right thing versus doing things right. It’s the destination versus the journey. Both are necessary. Being consistently inefficient will bankrupt you before long, but being ineffective won’t even get you a first sale. Therefore, no serious software project should be undertaken without a clear definition of the effectiveness we seek to achieve. Only improvisation genius Keith Jarrett could get behind a keyboard without a goal in mind and still produce a masterpiece – but that was a piano keyboard. Efficiency Is Relative, Effectiveness Subjective Effectiveness is fuzzy, unpredictable, and subjective. What do Seinfeld, Monty Python, Bohemian Rhapsody, and Star Trek have in common? They are all beloved popular classics that most people, including the critics, didn’t much notice or appreciate when they first came out. It’s no wonder many products fail, no matter how much market research you throw at it. There is no formula for creativity and no telling how people’s tastes can change. Efficiency is far less infuriating. The customer couldn’t care less what build tool or IDE the Spotify app was made with. It leaves no trace in the final product. Modern products are a complicated assemblage of parts from various suppliers. We choose parts for their efficiency in the hope they make an effective product that customers want to buy. But while each part is already effective from the supplier’s perspective when they make a sale, it only becomes efficient when it’s the right part. This extends to more than physical parts. Here's a real-world example of semi-conductor giant ASML, near my hometown. Morning traffic to the campus is hell, and public transport is only served by buses. The city council wants to lay a new bicycle lane to entice commuters living in a ten-mile radius to cycle to work. The goal is to get everybody to the office safely and fast by relieving the congestion for whom bicycles are not an option. The contractors building this road have no urgent stake in this efficiency drive, much less bicycle manufacturer Trek or Shimano, who supplies the gears and brakes to make the bikes run smoothly. But they all contribute to the effectiveness of the new road. Efficiency is relative, and effectiveness subjective. You get the point. Software is no different. The average enterprise product consists mostly of other people’s code you and your team can’t control (99.9% is a safe bet, certainly if you count the cloud stack you deploy to). Any component can be efficient in some places and useless elsewhere. A highly optimized caching mechanism backed by a dedicated Oracle enterprise is still a waste of money if you only need it to remember fifty numbers for an hour. Efficiency is about experimentation, making small tweaks, and swapping out slow/expensive components for better-performing ones. It’s a complicated, data-driven domain where computers feel right at home. Judging the effectiveness of software on the other hand is complex: it comes down to whether it ultimately makes the recipients happy. Who else but other people are qualified to answer that question and make the decisions? In the next post, I will focus on requirements/specification versus implementation and how they coincide with the efficiency/effectiveness distinction. In part three, I’ll discuss the famous alignment problem. Even humans fail at aligning software goals with their own interests and build expensive failures. How can we expect machines to do better? Then in part four, I will address our love of specialization, coding for coding’s sake, and why that will no longer be a competitive advantage soon.

By Jasper Sprengers CORE

Six Useful Resources for Engineers

Hi. I'm Alex Goncharik, and I've been working on Computer Vision and Deep Learning for more than five years now. Initially, I worked as a .Net Developer, but at some point, I came across an article about machine learning and became very interested in the area. I had a background in mathematics and Python, so I actively began to educate myself. At first, I watched video courses and read articles, then I started solving simple problems, and later, it became possible to switch to a project related to the use of computer vision technology. Two years ago, I joined the team behind iScanner, an AI-powered app for scanning and editing documents where we have the possibility to develop AI algorithms from scratch. For example, we implemented our own algorithms for getting rid of curves and skews and deleting fingers in scanned documents. I currently hold the position of Lead Computer Vision and Deep Learning Engineer at iScanner, BP Mobile (AIBY Group). My colleagues and I often discuss news related to our field and exchange articles and links. When you embark on your path as a professional, it can be difficult to find useful resources, so that’s why I've decided to share my recommendations with DZone readers. Some resources will be of interest to beginners, while others will interest more experienced professionals. MIT Deep Learning Book (Ian Goodfellow, Yoshua Bengio, Aaron Courville) This is the most comprehensive book available on deep learning and is available as a free HTML book. This text serves as an essential guide for anyone seeking to understand the intricacies of deep learning, from its fundamental concepts to its advanced applications. It covers a broad spectrum of topics, offers both theoretical and practical insights, and is accessible to learners of varying backgrounds. The authors don't just skim the surface of deep learning; they delve deep into the mathematical underpinnings that define neural networks, optimization algorithms, and regularization techniques. Grokking Deep Learning (Andrew W. Trask) This book stands out for its ability to bridge the gap between theoretical concepts and practical understanding, making it an ideal starting point for beginners in the field. The author skillfully breaks down complex ideas into digestible pieces, ensuring that even those without a strong technical background can follow along. Trask uses Python code examples and focuses on intuitive explanations that foster a deeper comprehension of the material. The code examples are relatively simple and might not cover the full breadth of advanced deep-learning techniques. Computer Vision: Algorithms and Applications (Richard Szeliski) This book is the gold standard in the domain of computer vision. Through case studies and practical scenarios, you gain insight into how computer vision is employed in fields like robotics, medical imaging, and augmented reality. Szeliski explains complex concepts clearly and transforms intricate ideas into understandable terms. It covers a wide range of topics, from image formation and camera models to advanced techniques like 3D vision and motion estimation. In addition, the book excels in its treatment of mathematical foundations. An Introduction to Statistical Learning (Gareth James, Daniela Witten, Trevor Hastie, and Robert Tibshirani) This book offers a comprehensive introduction to the foundations of statistical learning. It begins with fundamental concepts in statistical learning and progressively dives into more advanced topics, including linear regression, classification, resampling methods, and more. Real-world examples and case studies accompany each concept, solidifying understanding and illuminating how these techniques are applied in practice. One of the book's standout features is its integration of R programming for practical implementation. The accompanying R code allows you to replicate examples, manipulate data, and experiment with the presented algorithms. Collection of Lectures From Stanford University School of Engineering This compilation of lectures shows Stanford's commitment to sharing valuable insights and fostering intellectual growth on a global scale. This lecture collection is a deep dive into the details of deep learning architectures with a focus on learning end-to-end models for these tasks, particularly image classification. From this lecture collection, you will learn to implement, train, and debug your own neural networks, as well as gain a detailed understanding of cutting-edge research in computer vision. This is a unique opportunity to learn from some of the brightest minds in the field of engineering and technology. Stanford CS229: Machine Learning Course (by Andrew Ng) Andrew Ng has the ability to convey complex ideas in a comprehensible manner. His hands-on exercises provide learners with the opportunity to implement and experiment with machine learning algorithms. The curriculum progression is masterfully crafted, gradually leading learners from foundational concepts to more advanced techniques. While machine learning involves mathematical concepts, the course offers gentle explanations. Andrew Ng's expertise, coupled with the course's well-structured curriculum and practical assignments, creates an invaluable resource.

By Alex Goncharik

6 Proven Strategies for Being a Great Platform Engineer

“The future is still so much bigger than the past.”- Tim Berners-Lee, Inventor of the World Wide Web For platform engineers, the future is bright. Commonly thought of as the next stage beyond DevOps, platform engineers are one of the most in-demand and well-regarded positions in tech. While there is a huge upside to being on the cutting edge of an industry, there is one major, potential drawback: A lack of tried and true wisdom you can apply to the role. With the platform-engineering playbook still being written every day, I wanted to chip in with the best insights on being a successful leader and platform engineer I’ve heard from the best minds in our industry. The Wisdom: Success Is When Engineers Don’t Notice Your Work The expert: Kathryn Koehler, Director, Developer Productivity Engineering @ Netflix There’s no better measure of success for platform engineers than to have the developers they support free from being blocked, stuck, or disrupted. This is especially true when you’re building a fast-moving engineering juggernaut at Netflix, like Kathryn Koehler. According to Kathryn, when your work goes unnoticed, it signifies a seamless, smooth development experience. This allows developers to concentrate on building applications and features, accelerating the development cycle and delivering high-quality software. Ultimately, the goal of platform engineers is to create a stable and reliable platform that operates silently, enabling developers to excel in their work without unnecessary disruptions. The Wisdom: Eliminate the Most Common Sources of Toil, Like Testing The expert: Kaspar von Grünberg, Humanitec's founder and CEO Eliminating the most common sources of toil, such as testing, is crucial for platform engineers. This wisdom comes from one of the top leaders in platform engineering, Humanitec's founder and CEO Kaspar von Grünberg. Kasper rightly points out that by automating and streamlining testing processes, engineers free up valuable time and resources to focus on more impactful tasks. Removing manual, repetitive testing work not only increases productivity but also reduces the risk of human error while making developers happier they don’t have to wase their time. In the end, it allows engineers to allocate their expertise and creativity towards innovation, problem-solving, and improving the overall efficiency of the platform. The Wisdom: Focus on Making Your Team Complete With Diverse Skill Sets The expert: Charity Majors, CTO of Honeycomb.io Charity Majors’ charisma is just one reason she’s a great leader. The other? She knows how to build complete, diverse and complementary teams. Firstly, diverse skill sets bring a variety of perspectives, experiences, and expertise to the table, enhancing problem-solving and innovation capabilities. Different backgrounds and skill sets enable the team to approach challenges from multiple angles, leading to more comprehensive solutions. Additionally, diverse teams foster a culture of learning, collaboration, and mutual growth, as team members can learn from each other's unique skills and knowledge. A diverse team also ensures resilience, as it can adapt to changing requirements and tackle a wide range of tasks efficiently. The Wisdom: Keep the Whole Engineering Org Regularly Updated on What the Platform Team Is Thinking About The expert: Ambassador Labs' Katie Wilde Keeping the entire engineering organization regularly updated on the platform team's thoughts is essential — it fosters transparency, alignment, and collaboration across teams, ensuring that everyone is on the same page regarding platform developments and strategies. It can be as simple as what Katie Wilde suggests: Making a blog or short video about what she’s thinking about. She sends it off to her team and those small updates let the entire org know what a crucial member of their department is thinking about. These regular updates promote a shared understanding of the platform's direction, goals, and challenges, encouraging input and feedback from different perspectives. It enables other engineering teams to anticipate changes, plan their work accordingly, and leverage the platform effectively. The Wisdom: Automate Pull Requests and Code Reviews The experts: Dan Lines and Ori Keren, Co-founders of LinearB There’s probably no easier win for platform engineers than helping fix the No. 1 undiagnosed problem in software development: Massive bottlenecks in pull requests and code reviews. In helping engineering orgs get visibility into developer workflows with LinearB, Dan Lines and Ori Keren discovered that the majority of cycle time was being spent in pull request and code review. They found that: The average cycle time for a piece of work was 7 days Half of all PRs were idle for 50% of their lifespan Cycle time doubled when pull requests went from 100 lines of code to 200 lines of code The solution for this came in the form of gitStream, a tool that solved a host of issues keeping pull requests from being effectively picked up, including auto-assigning the best reviewer, adding estimated time to review, limiting PR size, segmenting PRs based on risk, and more. The Wisdom: Have Regular Meetings With Devs on What Their Problems Are The expert: Kelly Vaughn, Director of Engineering @ Spot AI Kelly Vaughn’s unique background makes her wisdom even more relevant. As a trained-therapist-turned-engineer, Kelly has a simple-but-impactful way to become the platform engineer your company needs: Find out the problems you should be solving based on unearthing the problems devs are actually having. These conversations provide an opportunity for platform engineers to understand the specific pain points faced by developers and gain insights into their needs and challenges. By actively listening to developers, platform engineers can identify areas where the platform can be improved, optimized, or customized to better support development workflows. This direct feedback loop fosters a collaborative environment where solutions can be brainstormed, prioritized, and implemented efficiently. By addressing developers' problems proactively, platform engineers can enhance developer productivity, streamline processes, and create a platform that truly meets the needs of the entire engineering team Proven Strategies for Being a Great Platform Engineer When an industry changes as fast as ours, advice can be obsolete by the time it gets written down. That’s why it’s important to tap into the real-time wisdom of people whose opinions you respect and careers you admire.

By Conor Bronsdon

How To Level Up in Your Data Engineering Role

Data engineering is one of the fastest-growing jobs in tech. And that isn’t surprising given the value — and sheer amount — of data that companies are capturing today. IDC forecasts that by the end of 2025, more than 175 zettabytes of data will be created, captured, and consumed – up from 33 zettabytes in 2018. Many companies have access to vast, growing amounts of data sitting in warehouses or customer data platforms (CDPs) but still don’t truly understand the potential value of their data. Companies can’t afford to lose these critical insights when it comes to making informed business decisions. Enter Data engineers. Landing a role in data engineering isn’t just about technical acumen. Of course, technical skills are a critical piece of the role, but to become a great data engineer, you need to understand the bigger picture of what problem you are trying to solve. Here’s how to get the role — and grow in your data engineering career. Learn the Language of Data Data engineers design, manage, and optimize the flow of data within an organization’s databases and develop data pipelines for analytics. But if you zoom out, data engineers are more than data shepherds. They are enablers in the organization, giving self-serve data access to the rest of the company. They can derive a single source of truth from complex, evolving datasets, working with data science and line of business teams such as marketing and product functions to help promote data-driven decision-making within an organization. Essentially, data engineers act as the translator of data to non-technical teams. While there’s no perfect roadmap or course of study to pursue to become a data engineer, a few must-have traits and qualifications will set you up for success. A data engineer should have the following: Proficiency in programming languages such as Python, Java, and C++. Effective data model design skills that accurately represent the structure and relationships of data. Database and data warehousing skills, including experience with SQL or NoSQL databases or data lakes. Experience with the Extract, Transform, and Load (ETL) or Extract, Load, Transform (ELT) processes to integrate data from different sources. Expertise in data governance, data pipeline, and workflow management. Understanding of modern data stacks and experience with tools that are used by specific teams (e.g., finance, HR) to gain insight into data. While you can study these skills and models, there is no replacement for experience. This can help budding data engineers understand the differences between a data warehouse and a data lake or the difference between SQL and NoSQL databases. These skills tend to ebb and flow as new platforms and ways of optimizing data are developed, so always keep an open mind and remain willing to learn new things as the industry continues to evolve. Don’t Overlook Your Soft Skills Development In addition to having the right technical tools in your toolbox to become a data engineer, soft skills such as communication, empathy, and collaboration are essential for success. It is very important to work closely with the line of business and understand what insights are important for them and why, so you can figure out how to create systems to enable them to self-serve those insights with speed and accuracy. I like to say data engineers play the role of the Great Translator — translating data insights for the teams, customers, and partners who need to understand them. Organizations rely heavily on data to understand what’s working and what’s not, both internally and externally, so it’s critical to communicate insights clearly and effectively. If you’re deciding between a career in software engineering or data engineering, I recommend asking yourself the question: do I want to head down the building, or am I energized by cross-functional communication and collaboration? Let your response guide you in your engineering career path. Empathy is also an important soft skill for data engineers to hone. Data engineers who don’t spend time talking with their customers miss an opportunity not only to solve complex problems faster but also to gain a better understanding of their customer’s business goals. With that knowledge, you can better serve your customers proactively and create a true partnership rather than just a vendor-client relationship. Finally, data engineers should prioritize collaboration. At Amplitude, we believe that product analytics is a team sport, where everyone from the product function to our data scientists and data engineers works together to solve problems and innovate as a unit. When data engineers share insights with the various cross-functional teams they support, early collaboration on the goals of the product ensures that the right insights are delivered and accurate goals are set. Put on Your Founder’s Hat I believe that the role of engineering within an organization is to increase the company’s capacity to win. It may sound daunting, but increasing your capacity to win can be broken down into lots of little (or big!) decisions. In making these decisions, my advice is always the same: put on your founder’s hat. I once had to learn this lesson myself. Years ago, I was faced with an engineering decision, and I outlined both options to my then-boss. He looked at me and asked, “If this was your company, what would you do?” I told him if I were CEO, I’d do option one, and that was the end of the discussion. It was a powerful perspective shift for me. Today, when I’m hiring, I look for people with this same mentality. Putting on your founder’s hat means you’re thinking business-first, not just engineering-first — and this is an important mindset for advancing your data engineering career. In a more recent example, I work with an engineering manager who is excellent at building products. They take ownership of readying the product for go-to-market and its success and have even created their own dashboard within Salesforce to understand which customers could find value in the product they are creating. In addition, they schedule a time to reach out. This is out of the normal realm of what a data engineer does daily and is a great example of pairing communication, empathy, and collaboration with technical chops. By thinking about how the product can be successful and taking into account the market and customer interest, they are looking to make the entire organization successful. They are wearing their founder's hat. I love Zig Ziglar’s quote, “Success occurs when opportunity meets preparation.” I believe this message applies to anyone looking to get into data engineering. There is certainly a need for both technical education and hands-on experience, but there is so much opportunity available for anyone willing to come to the table with an open mindset, ready to collaborate. If this sounds like you, the next level of your career in data engineering is waiting for you.

By Shadi Rostami

Performance Reviews Are A Waste of Time

At least weekly, I am asked for feedback or thoughts on a recent commercial interaction, most obviously for one-time transactions with a company rendering services; e.g., lawn service, gutter cleaning, teeth cleaning, financial, etc. Year over year, these requests increase (prefaced with, "And anything other than 5's is considered a failure...") and you start questioning the value-add. Tipping is a form of review. Returning or repeating customers are definitely a review of the services provided. Is there any actual value? But I digress. . . Image Source: "White Collar, c. 1940 - Linocuts by Giacomo G. Patri" by Thomas Shahan 3 is licensed under CC BY 2.0 In the United States, employee performance reviews are fairly de rigueur and pervasive for most jobs, especially for white-collar positions, but have you ever asked yourself what is achieved? Leaders can't wait to discuss ongoing problems if the problems would worsen. Performance improvement plans are often a precursor for firing chronic under-performers (except at Netflix). Career roadmap discussions or changes in career goals need to happen more than once per year. So what is the intended purpose of an annual performance review? My manager at my second full-time job started my review with the following statement: I have not done my job if you hear anything that we haven't previously discussed.- Jim D, CSC Consulting manager I found this incredibly useful and insightful, and often share this with managers and peers: feedback - positive or negative - should be in the moment, relevant, and continual for maximum impact. Of course, that assumes your manager actually tracks your work, which I've discovered is often not the case: multiple managers have asked me to write reviews for their peers! Performance reviews, in my opinion, are a perfunctory, HR activity rather than anything useful, and in the last 15 years, I have basically stopped any active participation, just the bare minimum effort to keep my manager out of trouble. My Turning Point I completed my first full year at Fortune 50 Company X, and, as expected, the new calendar year starts the performance review cycle. Performance reviews are serious business here: formalized, 360-degree feedback, scored, and time-consuming. If the scuttlebutt is correct, each year the lowest 10% are released to challenge and refresh the employee base. Personally, I'm not concerned: I've mastered the business domain, I've contributed positively to my project, my team functions at a high level, and I've expanded my reach into other parts of the org. The wrap-up meeting with my manager confirms this: I am top 10% for my role across the entire organization. Congrats, keep up the good work, we're lucky to have you. Whoo hoo! At the same time performance reviews wrapped up, project senior leadership changed, and managers meet with the new leaders to introduce themselves, their teams, and their responsibilities - normal stuff. My manager used the just-completed performance reviews to start the discussion about each person on her team. When it was time to discuss me, unprompted the new leader stated, "Scott likes to make people feel stupid." Wha?!? I had no idea where this comment came from: I had not met or worked with her previously, she hadn't yet been formally introduced, and my initial meet-and-greet was two weeks out. My manager was surprised and also had no idea what her opinion was based on. I was not specifically targeted, and there were others similarly surprised by her opinions. Regardless, I went from high performer to scum-of-the-earth overnight and realized quickly that image rehabilitation was difficult if not impossible. And If That's Not Enough... I've had other experiences that just further enhance my thoughts on the worthlessness of performance reviews. Mandatory Deflation After a poor fiscal year, one company instructed leaders to reduce review scores by 10% to reduce the annual bonus payouts. Wrong approach: performance reviews should reflect the quality (or lack thereof) of your work and a way to achieve corporate goals. Instead, I would have expected a proactive message from the president: I know everyone has worked really hard over the last year, and despite your hard work fiscally it's been a rough year. Therefore, I need to let everyone know that bonuses will be smaller than in recent years, for everyone at all levels. You should not take a reduced bonus personally: we must be fiscally responsible to better position ourselves for improvements this year. I know this is tough, but I hope you understand. Unfortunately, the company was not proactive and instead chose to game the system, frustrating everyone. Mismatched Role Expectations One company hired architects as Director Without Reports to ensure competitive salaries and bonus structures for their technology leaders. Unfortunately, the performance review scoring expected directors to manage direct reports, and therefore architects scored lower compared to other directors because of this. Our manager fought hard and diminished the impact, but it still impacted our raises, end-of-year bonuses, and opportunity for growth. Despite ongoing discussions, HR seemed incapable of understanding and made no changes to better reflect a reality they didn't grok. Unnoticed Non-Participation By now, I was totally jaded on performance reviews and did as little as possible, enough to not cause problems with my manager: complete self-review but don't provide any information; sign the printed review without reading or discussing; click whatever is necessary to move workflow along. I now knew this was to please HR and otherwise a complete waste of time. More recently, my overall self-review comment was: I am a penguin, prove me wrong. The first time I was surprised that no one noticed: not my immediate manager, not his director who supposedly reads reviews for all direct and indirect reports, not senior leaders who make salary/bonus decisions based on reviews. Not a peep, even when I didn't provide any other information. Leaders knew their team and had preconceived notions: the trusted, the hard workers, the laggards, the losers. No amount of formal performance review process would change that, but HR required the formality and so they went through the motions. Final Thoughts Let me be clear: for all the managers who dread performance review season and make the minimal effort required, there are those who view performance reviews as important to employees and make the commensurate effort. My wife believes her teams deserve reviews that are insightful, thoughtful, and personal, and spends hours on each person. Her meetings with each person look back at achievements - personal, team, organization - and forward-looking at upcoming projects and goals, and is a continuation of the one-on-one meetings held throughout the year. The result: a high-functioning team that understands business challenges, expectations, business, and personal goals. Perhaps my thoughts on performance reviews would be more positive with strong management earlier in my career, but unfortunately, that didn't happen. Now, in the later stages of my career, I've learned how to get my work done with and without the expected management support. Is it ideal? No, but it's the reality, and as such performance reviews have fallen off my list of things to trust.

By Scott Sosna CORE

Why Developers Should Contribute To Open Source

Open-source software has revolutionized the world of technology, enabling developers to collaborate, innovate, and build upon existing projects. One of the key pillars of open source is the involvement of developers from around the globe, offering their time, skills, and expertise to enhance and expand these projects. In this article, we explore the reasons why developers should actively contribute to open source and how it can benefit their professional growth and the software industry as a whole. Collaboration and Learning Opportunities Exposure to diverse perspectives: Contributing to open-source projects provides developers with an invaluable opportunity to collaborate with a global community of like-minded individuals. By working with people from various backgrounds, developers gain exposure to new ideas, perspectives, and approaches, fostering a rich learning environment. Enhancement of problem-solving skills: Open source projects often pose unique challenges that require innovative solutions. By contributing to these projects, developers have the chance to sharpen their problem-solving skills as they navigate through complex issues with the support of the open-source community. Access to mentorship: The open-source community is made up of seasoned experts who are often willing to offer guidance and mentorship to aspiring developers. By engaging in open-source projects, developers can tap into a vast network of experienced professionals, gaining valuable insights and advancing their skill set. Career Advancement Showcase of abilities and expertise: Open source contributions serve as a tangible demonstration of a developer's abilities and expertise. Employers value candidates who actively participate in open-source projects as it showcases their commitment, passion, and willingness to learn and improve continuously. Expanded professional network: Engaging in open-source projects allows developers to build meaningful connections with other professionals in the industry. These connections can lead to new job opportunities, collaborations, and professional growth, opening doors to further career advancements. Stronger resumes: Having open-source contributions listed on a resume adds depth and credibility to a developer's profile. It highlights their ability to work collaboratively, take initiative, and contribute to the software community, setting them apart from other job applicants. Growth and Improvement of Skills Learning from project codebases: Open source projects often have extensive codebases that expose developers to different programming languages, frameworks, and libraries. By studying these codebases and contributing to their development, developers enhance their understanding of best practices, coding standards, and optimization techniques. Refining coding and documentation skills: Contributing to open source encourages developers to write clean, maintainable code that is easily understandable by others. In doing so, developers refine their coding and documentation skills, making them more effective communicators and collaborators. Understanding software development workflows: Open source projects typically follow established software development workflows, including version control systems, issue tracking, and code reviews. By actively participating in these processes, developers gain firsthand experience and understanding of these workflows, preparing them for future professional projects. Making a Positive Impact on the Software Community Contributing to the greater good: Open source projects strive to provide software solutions that benefit the community at large. By actively contributing, developers become agents of positive change, helping to improve and advance the software industry as a whole. This sense of purpose and community is deeply fulfilling and can be a driving force for developers to continue contributing to open-source projects. Giving back to the community: Developers often rely on open-source software for their own projects. Contributing to open source is a way to give back to the community that has supported and empowered them throughout their careers. By sharing their knowledge and expertise, developers help create a virtuous cycle of growth and innovation within the software community. Conclusion Contributing to open source is a rewarding endeavor for developers, offering a multitude of benefits that extend far beyond coding proficiency. The collaborative and learning opportunities, career advancements, skill growth, and positive impact on the software community are all reasons why developers should actively engage in open-source projects. By participating in open source, developers not only enhance their own professional growth but also contribute to the advancement and evolution of the entire software industry. So, let's embrace the power of open source and join the thriving community of developers working together to build a better future.

By Ravi Jadhav

Visualizing a Career Path

If you work for a larger organization, the chances are that you may sooner or later find yourself reporting to someone with a very different background and, as a result, perspective on an organization, roles, etc.; for example, someone with a developer background reports to a marketer. Trying to explain a career and how it has led you to a place and how you might wish it to progress is difficult if the person you’re talking with has little exposure or understanding. Or, it could be simply that the person you’re talking to is a visual thinker. This is where I found myself recently. So, to facilitate a conversation, I thought I'd try to describe my career and desired direction more visually. After all, CV-style bio/representations are rather abstract, focus on a timeline, and need a domain understanding to appreciate the value. Visualizing an Organization To visualize an organization everyone can relate to, the representation must be pretty generic and true to many organizations. The following might not fit every organization, but it should fit any organization with an engineering element, whether software, architecture, or widgets. The size of each segment may fluctuate between organizations, but that is less of an issue than the ideas they represent. A simple abstract representation of a business Let’s bring this diagram to life a little more by showing how different parts of the organization sit in the Venn diagram. While the following diagram with its callouts creates more of a specific spin, we’ve avoided organizational-specific names. The simple diagram has now been given some "life" and "context" by pinning roles to it. You’ll note that leadership sits in the center, not because that could be perceived as the most influential and important part of the diagram, but because most leaders have a solid grasp of most aspects of a business. If we assume the further toward the outer edge of each area, the more we’re focused on the skills of that space. Where we have overlap, we see a blending of skills. You may argue with some jobs attributed to the overlapping areas – for example, does a consulting role use sales and build (engineering) skills? From my experience, it does as you need to make compelling arguments for a solution, often needing to understand what the customer wants to "buy." Plotting a Career Path With this, we can plot our different roles, and how we link the different points shows our career trajectory. I’ve added my career to illustrate the point – you can compare this against my LinkedIn profile if that helps. We’ve now plotted our career journey on the diagram. Notice how my path fluctuates in the "Build Stuff/Sell Stuff" area as it reflects the shift in and out of consulting roles. With the path plotted and with callouts highlighting facts that may be important to a conversation. For example, suppose I wanted to move in the direction of announcing stuff (i.e., marketing). In that case, it will be a real stretch out of my comfort zone, given that my career has always had a solid engineering basis. We can plot our career aspirations and even the possible steps we want to progress such a journey. We’ve added to the path a line indicating an aspiration to go into a pre-sales role. You could even derive from how it has been drawn that an interim step could be moving back to a consulting role. As you can see, it becomes much easier to suggest and infer aspects of someone’s possible career path and aspirations. Even without any genuine appreciation of roles and likely skills involved, it would be pretty reasonable to infer such a career journey is going to stretch, and it may even involve an interim role to help the transition. At this point, this isn’t a career path I am looking to take. Becoming More Scenarios in the Same Role But what if you want to stay in the same role but progress in seniority? I would suggest that visualization will still help provide positioning and context within the organization. But rather than illustrating the career path with just an x-y axis, we probably need to use an additional axis or shape and size. For example, showing gaining seniority with concentric rings. For example: Visualizing a career reflecting growth through promotion in the same function In the diagram, the rings are also colored slightly differently to help make each one distinguishable. But using increasingly larger rings to help show increasing seniority in the same role covers more space on the diagram, reflecting a typical increase in scope for the role. Conclusion I’ve found this visualization helpful to both help me think about my career path and express what I hope to achieve going forward. It has also helped me appreciate that my career has perhaps had more lateral movement than vertical in terms of responsibilities, but experience has grown the scale of potential influence. The true test of this is if you can just provide the diagram without the supporting written narrative. The diagrams have been created with points and can be found here. Feel free to take the presentation and put it to use. All I ask is that if you find it helpful, let us know, and please try to acknowledge the source.

By Phil Wilkins

Career Development

DZone's Featured Career Development Resources

Top Career Development Experts

The Latest Career Development Topics