Rust 2021 is the third edition of the language. Editions in Rust are opt-in updates that introduce features that are backwards incompatible. Since they are opt-in, developers won’t see the changes unless they decide to migrate to that edition. 

According to the team, crates in one edition are interoperable with crates compiled in a different edition. “This ensures that the decision to migrate to a newer edition is a ‘private one’ that the crate can make without affecting others,” the Rust team wrote in a blog post. 

RELATED CONTENT: What’s all the fuss about Rust?

One change being made in this edition is a new prelude, which is a module that contains the things imported automatically in every module. Adding a trait to the prelude can break existing code, but as a workaround, Rust 2021 will include a new prelude that has three additions over the current one: std::convert::TryInto, std::convert::TryFrom, and std::iter::FromIterator. 

This edition will also introduce a small workaround to IntoIterator, which currently causes breaks to existing code. “In Rust 2015 and 2018 code, the compiler will still resolve array.into_iter() to (&array).into_iter() like before, as if the trait implementation does not exist. This only applies to the .into_iter() method call syntax. It does not affect any other syntax such as for e in [1, 2, 3], iter.zip([1, 2, 3]) or IntoIterator::into_iter([1, 2, 3]). Those will start to work in all editions. While it’s a shame that this required a small hack to avoid breakage, we’re very happy with how this solution keeps the difference between the editions to an absolute minimum. Since the hack is only present in the older editions, there is no added complexity in the new edition,” the Rust team explained.

Rust 2021 will also introduce a new feature resolver that no longer merges all requested features in crates that are dependencies. 

In the new edition, closures, which automatically capture whatever is referred to from within their body, will only capture the fields they actually use. 

Rust 2021 will introduce a more consistent panic!() macro as well. The new macro won’t accept arbitrary expressions as their only argument. 

This release will also reserve some syntax to make space for new syntax down the line. It will reserve prefix#identifier, prefix”string”, prefix’c’, and prefix#123. 

In addition, it will make two existing lints hard errors instead of just warnings as they are currently. The use of the keyword dyn to identify trait objects will be mandatory, and the deprecated … syntax for inclusive range patterns won’t be accepted anymore. 

Finally, in Rust 1.53, patterns were extended to support | nested anywhere in the pattern, which enabled developers to write Some(1 | 2) instead of Some(1) | Some(2). This change affects macro_rules macros because they can accepted patterns using the :pat specifier, but :pat doesn’t match |. Starting in Rust 2021, the :pat fragment specifier will be able to match A | B. 

These features are the final features that will be available in Rust 2021. They were decided upon by the Rust 2021 Working Group by meeting two criteria: 1) they had to be approved by the appropriate Rust team, and 2) their implementation had to have been far enough along that the group was confident in their ability to be completed in time for the planned milestones. 

The Rust 2021 Working Group plans to have these changes merged and tested by September in order to ensure Rust 2021 can be added to Rust 1.56.0. Rust 1.56.0 will be in beta for six weeks and released as stable on October 21st. It will release another announcement on the new edition in July, at which point all changes should be implemented and ready for testing. 

The post What to expect in Rust 2021 appeared first on SD Times.

Let’s face it, no one would do that. A rational person would first figure out what the house should look like, the number of rooms it needs to contain, how the rooms are connected, etc. When the plans for the house are complete, then the correct amount of supplies can be delivered, the tools taken out, and construction begun. Architects work with paper and pen to plan the house, then, and only then, carpenters work with tools and lumber to build it. Everyone associated with home building knows that you figure out what is wanted before determining how to build it.   

RELATED CONTENT:
The most uninteresting reason your project might fail
5 tasks project managers must perform to ‘sell’ their proposals

Arguably, the fundamental principle of systems development (FPSD) is also to figure out what the system is supposed to do before determining how to do it. What does the user want? What does the system have to do? What should system output look like? When the what is understood, then the how can start. How will the system do it? How should the system generate needed output? The how is the way users get what they want.

The IT industry has long recognized that confusing the what with the how is a major cause of project failure resulting in user dissatisfaction from poor or absent functionality, cost overruns, and/or missed schedules. Ensuring that the what is completely understood before attempting the how is so important that it was engraved into the dominant system development life cycle methodology (SDLC) of the time—the waterfall approach. 

For those of you who just recently moved out of your cave, the waterfall SDLC consists of a series of sequential phases. Each phase is only executed once, at the completion of the previous phase. A simple waterfall approach might consist of five phases: analysis, design, coding, testing, and installation. 

In this approach, the analysis phase is completed before the design phase starts. The same is true for the other phases as well.

The good news is that with the waterfall approach, systems developers did not have to remember to put the what before the how because their SDLC took care of it for them.

Then iterative and/or incremental (I-I) development came along and, the rest, as they say, got a little dicey.

Although there are dozens of I-I approaches, they are all variations of the same theme: make systems development a series of small iterative steps, each of which focuses on a small portion of the overall what and an equally small portion of the how. In each step, create just a small incremental part of the system to see how well it works. Vendors like to depict I-I development as a spiral rather than a waterfall, showing the iterative and incremental nature of these approaches.

Using an I-I approach such as prototyping, a session might consist of a developer sitting down with a user at a computer. The user tells the developer what is needed, and the developer codes a simple solution on the spot. The user can then react to the prototype, expanding and correcting it where necessary, until it is acceptable. 

This is obviously a very different way to develop systems than the waterfall approach. What might not be so obvious is that the various I-I methodologies and techniques, such as rapid application development, prototyping, continuous improvement, joint application development, Agile development, and so on, still involve figuring out what is wanted before determining how to do it. 

Rather than looking at I-I as a picturesque spiral, an I-I approach can be viewed as a string (or vector for you programming buffs) of waterfall phases where each cycle consists of a sequence of mini-analysis, mini-design, etc. phases. However, rather than each phase taking six months they could be no longer than six weeks, or six days, or six hours.

It might take a half-dozen cycles of sitting down with a user to figure out the requirements (the what) and then coding the results (the how) before showing them to the user for additional information or changes, but the principle is always the same—understand the what before determining the how.

However, too many developers throw out the baby with the bathwater. In rejecting the waterfall approach, they mistakenly ignore the basic what before the how—the FPSD. The result is the reappearance of that pre-waterfall problem of project failure resulting in user dissatisfaction from poor or absent functionality, cost overruns, and/or missed schedules.

Why? How could something so well understood as ‘put the what before how’ be so ignored? Here are three common reasons for this troublesome behavior.

Reason 1. Impatience (Excited to Get Started)—Many in IT (the author included) started their careers as programmers. Programming is a common entry-level position in many system development organizations. It is understandable that new (and not so new) project team members are anxious to start coding right away. In their haste, FPSD is not so much ignored as short-changed—corners cut, important (sometimes annoying) users not interviewed, schedules compressed, etc. The result is an incomplete understanding of exactly what the users want.

Reason 2. Not Understanding the Value of Analysis—Analysis, or whatever your call it (requirements, logical design, system definition, etc.) is the process of learning from users their requirements (the what) and then documenting that information as input to system design (the how). However, analysis has endured some heavy criticism over the past few decades. Some feel that it is overly laborious, time consuming, error prone, or just not needed at all. The result can be an incomplete understanding of what the new system needs to do.

Reason 3. Confusion about the FPSD and the Waterfall Approach—The waterfall SDLC is viewed by many as a relic of IT’s past, offering little for today’s developers (not entirely true, the waterfall approach still has its uses, but that is a subject for another time). Unfortunately, the what-how distinction is closely tied to this approach so any rejection of the waterfall approach contributes to skepticism regarding any what-how talk.

What’s a project manager to do? How do you ensure the what is understood before the how is undertaken? There are three things the project manager can do.

Training—The problem with most systems development rules and guidelines is that the reason they should be followed is not always obvious. Or has been forgotten. Systems developers tend to be an independent and skeptical bunch. If it was easy to get them do to something, then documentation would be robust and project managers would earn half what they do now because their hardest job would have disappeared. No, managing a team of developers is like teaching an ethics class in Congress—difficult, underappreciated, and often exhausting. The one saving grace is that systems developers like to create great systems. The vast majority of developers take great pride in doing a good job. The project manager needs to tap in to that enthusiasm. 

The easiest way to get systems developers to do something (other than forbidding them from doing it) is to convince them that doing it is in their and the project’s interest and that separating the what from the how is in that category.

But wait. You can hear the challenge right now. “We are using Agile development, so we don’t need to separate the what from the how.”

The answer is that the purpose of the what-how distinction is not to create separate development phases but is to make developers think before they act—to ensure that before the design hits the page or a line of code is entered on a screen, the problem is mulled over in those high-priced heads.

Is this approach counter to Agile development or any iterative-incremental approach? No. Read the books and vendor manuals more closely. There is not one author or vendor who believes you can skip the thinking if you use their tool or technique. The problem is that many of them are not sufficiently vocal about the value of thinking before acting.

Discipline—The problem is usually not knowing (most know to complete the what before starting the how), the problem is doing. A good way to get team members to do the right thing is to codify the desired behavior before the project kicks off. Rules, standards, and strong suggestions presented before a project starts are more likely to be accepted and followed by team members than mid-project changes, which can be seen as criticisms of team member behavior.

The project manager needs to lay out the project rules of engagement, including such things as the SDLC method or approach to follow, the techniques and tools to use, documentation to produce, etc., all focused on ensuring the what is completely understood before starting the how. 

Then comes the hardest part of the entire project—enforcement. The project manager needs to ensure that the rules of engagement are followed. Failure to enforce project rules can undercut the project manager’s credibility and authority. A few public executions early in the project do wonders for maintaining that project manager mystique.

Collaboration—Want to influence a systems developer? Need to convince developers to follow systems development best practices? Then have him or her collaboratively meet with other systems developers. The team walk-through is a great vehicle for this.

In a team walk-through the developer presents, demonstrates, and defends his or her work, not to users, but to other team members. The developer walks the other team member through the user requests, his or her analysis of those requests, their solution to the request, and finally any demonstrable work products. This friendly IT environment is a useful way to test if the developer’s work is thorough, efficient, and complete.  

This is should be a slam-dunk. Team walk-throughs can be very motivational, inspiring (shaming) underperforming developers into producing better results while providing overachievers an opportunity to show off. In both cases, the user, the project, and the project manager win.

George Tillmann is a retired programmer, analyst, systems and programming manager, and CIO. This article is adapted from his book Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes (Stockbridge Press, 2019). He can be reached at georgetillmann@gmx.com.

The post Confusing the What with the How appeared first on SD Times.

Additionally, 91% of respondents would like to use Go for their next new project, and 89% find it is working well for their team. The results are based on 9,648 developer responses. “Understanding developers’ experiences and challenges helps us measure our progress and directs the future of Go,” the team wrote in a post. 

RELATED CONTENT: Why developers love Go

The language’s top features, according to respondents, include build speed, reliability, using concurrency, CPU usage and editor support. VS Code is the preferred editor with GoLand following closely. Respondents are also having success with its cloud services, debugging and modules. 

Overall, 92% of respondents say they are satisfied or somewhat satisfied with the language. Eighty-one percent of respondents find they are very or extremely productive with Go, and 93% stated it took less than one year to become productive with Go. Of that 93%, 31% found themselves more productive between one week and one month of using Go, and 33% were more productive between one month and three months. 

The report did find a downwards trend of those who stated they feel welcomed by the Go community. Only 78% of respondents reported feeling welcomed this year compared to 84% in 2017. When asked what would make them feel more welcome, respondents stated more learning resources and docs, improved contributor experience, and maintainer attitudes. 

The top use cases for Go include: API/RPC services, CLI, libraries or frameworks, and web services. 

The top reasons for not using Go include working on a project in another language, the team prefers to use another language, and Go lacks a critical feature necessary to do their work. Top challenges include lack of generics, modules/package management, and problems with the learning curve. 

The post Report finds Go is becoming more critical to a company’s success appeared first on SD Times.

“With Power Fx, we can amplify the impact of developers by many multiples over the same time horizon. By offering citizen developers a familiar and approachable way to express logic, we’re dramatically expanding who can build sophisticated solutions. By delivering Power Fx with the tools a professional expects, including the ability to directly edit apps in text editors like Visual Studio Code and use source control, we’re making it possible for developers to go faster and find common ground with millions of makers,” Ryan Cunningham, director PM of Power Apps at Microsoft, wrote in a post. 

RELATED CONTENT:
Microsoft plans for low code with new updates to the Power Platform
New mixed reality platform Microsoft Mesh to enable shared experiences from anywhere
Visual Studio 2019 v16.9 and v16.10 Preview 1 and .NET Upgrade Assistant preview
Businesses in 2021 think high for low code

Since the language is open source, the language will be available for open contribution and innovation. Additionally, it is built for the low-code world, and will be able to extend across Microsoft’s Power Platform, Dataverse, Power Automate, and Power Virtual Agents. 

“The truth is, point-and-click tools are great for quickly assembling experiences and workflows, but many real-world solutions need a layer of logic that goes beyond what is practical to drag and drop,” Cunningham explained. 

The motivation behind the language was to develop something that was familiar to Excel users, content-centric instead of program-centric, and have the ability to recompile in real time. 

Since Power Fx is based on Microsoft Excel, it provides similar syntax, functions and behaviors. For instance, formulas are declarative and recalculate instantly. This helps ensure everyone works from the same source of truth and frees developers up from having to manually update variables and data tables, according to Cunningham. 

The post Microsoft open sources a low-code programming language for all appeared first on SD Times.

According to MIT CSAIL, many programming languages are classified as domain-specific languages (DSLs), which are languages that have been adapted in some way from traditional languages and designed for use by non-programmers. 

One issue with DSLs, however, is that they can be difficult to create. For example, if one wants to create a new DSL from C++, they’d need to hire an expert to design it by looking at programs the team has already written to determine what elements need to be incorporated, and they would also need to write a new compiler, parser, and code generator, the team explained.

BuildIt aims to eliminate the need to hire an expert. It acts as a multi-staging framework to reduce the complexity of a language down to a set of a few common features.  Developers will be able to use BuildIt to create DSLs just from taking their existing programs and making a few changes. 

“BuildIt doesn’t have a full view of the program, instead examining it through the narrow window of individual simple operations happening in the program, like multiplication and division,” said Ajay Brahmakshatriya, PhD student at MIT CSAIL who co-wrote a new paper on the system with MIT professor Saman Amarasinghe. “It’s the equivalent of a person walking through a maze: even if they can only see one part of it at a time, they can navigate it by recording their observations and leaving markers on different paths they’ve explored.” 

Amarasinghe also noted that he hopes BuildIt will inspire non-programmers to use programming in their work since they can use these DSLs without much programming knowledge.

“With BuildIt, anybody with the knowledge of the application domain, from a physics researcher to a vaccine developer, can write their own DSL instead of creating a large library,” he said. “That opens up a lot of exciting possibilities in terms of pushing forward new innovations in the coming years.”

The post MIT CSAIL researchers develop tool for creating domain-specific languages appeared first on SD Times.

A question I often hear is, ‘How do you assess a developer’s work, and his/her worth to the organization?’

Some organizations still cling to the metric of lines of code produced by a developer, which — given the extra responsibilities of testing, ensuring security, adhering to policies and regulations, and more — might not be a fair valuation in today’s complex world. 

This method is entrenched in the finger-pointing of the past, which modern development organizations have largely eschewed as they look to create a blameless culture.

Forward-thinking companies will look at the role of the team around development, assembled with software engineers, testers, security experts and people from the business side, and look holistically at how that team performs.

“Line counts is a terrible metric, and I think we all agree on that,” said Chris Downard, vice president of engineering at Gigsmart, a website for hiring gig workers. “There are times … when it could be useful as an additional data point, but not necessarily for information.”

When you’re managing humans, he said, reducing every action to data points is not good. Time must be spent building context, as data can often misrepresent things. At Gigsmart, Downard said they don’t use sprints, instead taking what he called “an ongoing, non-stop kind of combat approach.” But they do use sprint reports, from metrics captured every two weeks, to communicate what happened in that time period.

He pointed out he knew what his team was doing between the sprint reports — they were working hard, pairing up, and he saw the number of merge requests going up. “But one of the normal indicators of productivity is, ‘are we moving things across the line to delivered,’ as points completed,” he said, and that number was going down. But based on their knowledge of the team and of the context of everything else going on, they discounted the number, knowing the team’s productivity was very, very high. “It’s just the way the ticketing shook out, producing a data point that was not necessarily indicative of what was accurate,” he noted.

As an organizational leader, Downard said, you need to think about the things you want the organization to produce, and then think about the measurements that will indicate that you’re having success or struggling. Different teams, of course, have different goals.

“If you’re running a DevOps team, you might care about time to resolution, and if you’re tracking the development portion of an IT department, it might be turnaround time for customizing reports and data stuff. You need to track the things that matter to your organization’s success. So for us, I track merge request counts for a week. And we don’t necessarily do anything with that data. It’s not a carrot-and-stick thing. It’s just, it gives me additional information. Kind of like a doctor would be diagnosing a patient.”

But data points often don’t align with assessing developer productivity because while much programming involves the logical reasoning side of the brain, it also involves the creative side. So for Downard, raw data points are “typically terrible. But what we do get is a lot of soft indicators. You get information out of standup updates of people communicating how they feel about what they’re doing. You get hard data points in the sense that you can see their commit activity, but you have to keep context.” As a leader, he said, you have to advocate for developers and translate what they’re running into, to every other organization around development.

Downard said Gigsmart uses Bushido, the samurai code of conduct that defines the values of how you should act and conduct yourself as an individual, as its organizational ethos. “Jason Waldrip, our CTO and I sat down and crafted it into a set of ideals to drive the organization, and I use that as the core for everything we do. So if I’m going to start tracking something, it has to map to some sort of value from there, because if I try to track things that don’t map well to those values, I can’t advocate for those values with the team. It’s not gonna stick, it’s going to become hollow.”

Data points, he said, are nothing more than signals to go look into something and start asking questions. “And it should always be exploratory, not accusatory. That’s important to us. 

The post Industry Watch: Assessing a developer’s work, and worth appeared first on SD Times.

“Today’s massive codebases make it difficult for developers to discover, understand, and fix code because of the significant increase in its volume and complexity,” said Quinn Slack, co-founder and CEO of Sourcegraph, a universal code search company. “It’s for this reason that Big Code is often compared to Big Data—both have the potential to disrupt teams, decrease productivity and quality, and make it harder for enterprises to stay competitive.”

With the emergence of Big Code comes the emergence of new big problems. According to Sourcegraph’s Slack, the amount of code being created has exponentially increased; the complexity of languages tools and processes are continuing to multiply; accelerated delivery cycles are changing code faster than ever; and the value of code has become more important within the enterprise. 

Sourcegraph recently conducted a survey on the emergence of Big Code, and found:

• 94% of respondents are affected by Big Code; 
• 51% have 100 times more code than they did 10 years ago; 
• Over 60% are seeing a dramatic increase in architecture, supported devices, use of open source, and amount of platforms; 
• And 92% feel pressured to release code faster. 

As a result, the report found development teams are finding it harder to include time for new hires to be productive, understand code dependencies, manage changes, provide visibility, and have effective code reviews. Additionally, 74% of respondents reported that their teams avoid updating code because they are afraid of it breaking dependencies. 

When looking at how Big Code impacted the entire business, the report found problems with maintaining high-quality standards, high security risks, delayed release schedules, increased costs, decreased agility, and inability to innovate. 

While approaches like microservices were designed to simplify the development of applications, Slack said they introduce more complexity and increased code interdependencies. 

“The scale and scope of Big Code stretches devs and companies in every way, and we’ve only seen these challenges amplify over the last decade. Building software takes longer, is more complex, and there’s more fear involved because security risks allow no margin for error,” said Slack. 

To address Big Code challenges, Slack explained new tools will be key. For instance, 85% of respondents think existing tools weren’t designed for the era of Big Code, and 99% believe they would benefit from additional capabilities for searching enterprise code such as alerts for security and compliance risks, ability to search code regardless of repository, language, change or format, and finding code by querying semantic relationships. 

According to Slack, “the solution is to make code more accessible, manageable, and fixable. Companies should be asking: 

1. Is there one place in our company we can go to look across all of our code and instantly find problems and critical security issues?
2. Once we’ve found them, can we easily understand and measure them?
3. Once we can understand them, can we fix them quickly?” 

“Most companies are operating like tech companies today. There are more developers managing higher volumes of code and more challenging complexity than ever before. Every dev knows this intuitively, and we’ve collected data that validates the heroics it takes to ship software every day,” Slack added. 

The post Report: The emergence of Big Code comes with big problems appeared first on SD Times.

According to Phil Hughes, front-end engineer at GitLab, it’s about how you provide and convey that feedback — and that’s an art form and a skill that is learned over time. “Reviewing code efficiently is a skill that gets learned the more you do it. Spending time coming up with a workflow that works for yourself is just as important,” he wrote in a blog post.

Here are some tips and tricks to perfect your code review process and to help teams get on the right path:

Decide how you want to do code reviews: According to Sandya Sankarram, software engineer at SurveyMonkey, there are three ways to do a code review: 1. Group walkthroughs where code is reviewed as a group in person. The benefits of this is the ability to debate about concerns and feedback in real time. 2. Pair programming where two developers work together with one writing the code and the other observing and offering advice along the way. 3. Pull request code reviews where code reviews happen offline; reviews, changes and feedback can be added line by line, and feedback can be given through commits. 

“It’s like having a proofreader look at what you’re writing and hopefully they see something you don’t see. Sometimes it is about reviewers having more expertise of the particular file and a particular repository so they can give you extra context on the thing you might be changing or identify a potential issue,” said Jarred Colli, head of product for Bitbucket at Atlassian.

Manage time effectively: One of the top challenges of code reviews is making sure developers allocate enough time to review each other’s code. “It’s not uncommon for somebody to submit a pull request and wait two weeks for their teammates to give them feedback before it can be merged,” said Colli. “Ultimately, the goal for development teams is to merge high-quality code quickly. Some people err on the side of making sure the code is high quality. Some people prefer to err on the side of making sure that it’s done quickly. The goal is to try to do both.”

One way to do both is to make sure code doesn’t stay unmerged for long periods of time. The less time it stays unmerged, the less opportunity it has to change or cause potential problems, according to Colli. Colli added pull requests should be reviewed by teammates within a couple of days and then get merged. 

According to GitLab’s Hughes, individual developers should find a time in their daily routine that works best for them. For instance, he finds starting his day off with code reviews for him provides less distractions and more productivity. Additionally, Hughes says to have an agreement for how long code reviews should take. GitLab has a 2-day Service Level Objective for reviewers to get feedback to developers. 

Keep it short and simple: There is an inclination to put all changes together in one large package and then make it available for everyone to review. This makes the process confusing because there could be multiple files changing simultaneously, making it hard to effectively review the code. It also reduces the likelihood team members are going to find problems. “Developers are so busy with a million different things, it’s hard to sit down and do that all at once. They end up having to come back to the review multiple times, they might skip a file, lose their place, or forgot what they read before,” said Colli.   

Tightening the feedback loop between writing the code and getting feedback also prevents developers from getting too attached to the code and then getting defensive over changes being made to it, according to Erik Dietrich, a programmer and co-founder of the technical content marketing firm Hit Subscribe. Pair programming works well here because developers are closely aligned so when they make a mistake they can immediately get that feedback. 

Automate when possible: According to Aki Asahara, CEO of the software development company Sleeek, about 30% or more of a team’s working time is made up of code reviews. By being able to automate parts of the code review, it can save time and enable higher-quality code. Asahara explained that a majority of code reviews involve just checking the state and style of the code. With an automated tool, teams can write custom policies or rules so developers don’t have to worry about spellcheck or repetitive tasks, and they can deal with more essential parts of the code. 

Atlassian’s Colli explained there are a lot more automated tools coming out to help support and reduce the amount of time it takes to perform a code review. Code insight tools can help identify dependencies and issues to let developers know if things need to be updated and provide more context around code that is being changed. Security scanning tools can help find potential vulnerabilities. 

Having automated tools also takes pressure and conflict off developers and teammates, according to Dietrich. He explained developers tend to have negative connotations towards reviewers because they feel like they take too much time or nitpick their code. “And beyond the interpersonal dynamic, automated reviews are relatively infallible. [Automated tools] won’t miss something because they haven’t had their coffee yet, or because they’ve been at this for hours, it’s Friday, and they want to knock off for the day,” said Dietrich. 

Have a checklist: Atlassian’s Colli explained it can be difficult for teammates to confirm that the reviews have been done and the suggestions and feedback were appropriately acted upon. A checklist could include whether or not the code reviewed feedback; was anything done about it; was it done the way it was suggested to be done, why or why not?

Take advantage of merge checks or branch restrictions: Similarly to custom policies, merge checks or branch restrictions can set conditional rules in place before a pull request can be merged. “The more structure that you can add to the back and forth between teammates providing feedback, the better off you are going to be,” said Colli. For example, a check can be to make sure the code was checked and approved by at least two reviewers before it can move on; or if a security vulnerability is identified by the security scanning tool the code won’t be merged. 

Take advantage of talent: One strategy is to find developers who understand the complexity of the code or who are an expert in the area of the code being checked so they can provide feedback about any risky changes, according to Colli. 

Use code reviews as a teaching opportunity: Code reviewers help developers become more familiar with the codebase, but it’s also an opportunity for senior developers to help junior developers by telling them how they could have been more effective. “Few people realize the impact on knowledge sharing and mentorship code reviews have on a team. They are a tool to help engineers grow faster (junior engineers see seniors’ code more frequently), get better at mentoring (giving constructive feedback),” Gergely  Orosz, an engineering lead at Uber, wrote in an email to SD Times. 

Without code reviews, the software development process can suffer from “less knowledge sharing, more easily preventable mistakes going into production,” and code that is “often less readable as a result,” he explained. 

From meaningless to meaningful code reviews
Code reviews can be a source of anxiety and misery for groups that are more sensitive and appreciate polite gentle feedback. But on the other hand, code reviews can also be great for groups of people who appreciate direct and honest feedback, no matter how blunt or brutal it may be. “For the latter group, code review is great; it’s a chance to duke it out over strongly held personal beliefs with (theoretically, in their minds) no hard feelings,” said Dietrich.

It doesn’t have to be one way or another. According to Sankarram, there is some middle ground. 

In a talk on “Unlearning toxic behaviors in a code review culture,” Sankarram pointed out some toxic behaviors she and others have experienced as well as provided recommendations to improve code review culture.

“Please keep in mind that I’m not discouraging feedback. I’m just making a plea for people to govern their tone and the way that they choose to deliver the content of their feedback,” she said in her talk.  

Don’t pass your opinion off as fact: Unless you can provide proper resources and documentation to back up your claim. According to Sankarram, this is common when it is a question of style and syntax. She recommended implementing a linter or automatic code fix so team members can see what style guidelines they should be following. “You should be fostering debates and not making demands,” said Sankarram.

Dietrich explained saying “that’s wrong” or “that’s bad” can cause developers to be defensive. “Contrast that with a statement like ‘that’s not what I’d have done there,’” which is essentially inarguable. Even better, though, I’ve found, is to ask questions instead, like ‘why did you choose that implementation,’ or ‘couldn’t that lead to a race condition?’” he added.

Using opinions instead of fact can also waste developers’ time arguing over subjective concerns. “If you have domineering reviewers that are providing feedback that’s completely non-actionable or arbitrary, it creates learned helplessness in the subjects of that review.  They learn to do a pretty minimal amount of effort, since the domineering personality will pick apart everything they do anyway,” said Dietrich.

Don’t leave an overwhelming amount of comments: “When a person makes an error, chances are that they’ve made the same error in several places,” Sankarram explained. Instead of leaving comments in every single place the error occurred, simply leave detailed notes with helpful links and resources so you are conveying your message, but not overwhelming the developer. 

Don’t ask reviewers to fix problems: If there are issues within the code that aren’t directly related to the reviewer’s change, it becomes a separate discussion. 

Don’t ask judgmental questions: This is unhelpful and implies that the developer should have known about a simple solution. It also forces the developer to have to defend their work. Instead, you could recommend they do it a different way rather than using harsh and judgmental words such as “Why didn’t you do it this way?” said Sankarram. 

Don’t be sarcastic: Code reviews are not the time to be sarcastic, it is a time to offer someone feedback. “Saying something like ‘Did you even test this code before checking it in?’ is sarcastic, it’s rude and it gives no context or actionable feedback. It is better to describe the problem and not waste time,” Sankarram explained. 

Don’t use emojis to convey feelings or point out issues: For instance, Sankarram has seen the thumbs-down or puke emoji used in previous code reviews. Emojis, while fun, are cryptic and easy to misunderstand as well as wastes people’s time trying to figure out what the emoji means. 

Don’t ghost people: Developers seeking code reviews can also contribute to the toxic culture by not responding to feedback, leaving people wondering why they even bothered to help you in the first place. If you don’t agree with something or are not going to make a particular change, let the reviewer know why. 

Don’t ignore toxic behaviors: It’s typical to deemphasize behavior especially if it is coming from a high performing or productive developer, according to Sankarram, but these developers still need to understand that their behaviors are stressful and draining and not helpful to other team members. “The stakes are pretty high, not taking steps to unlearn these toxic behaviors have serious setbacks for the team as developers feel overwhelmed, attacked and unmotivated. They start to draft these feedback processes that are supposed to help them grow,” Sankarram said.

Dietrich also suggested code reviews should be bidirectional and includes all team members regardless of the experience level. Also, letting team members pick their own code reviewers can help them be more comfortable with the review. 

“You want to make sure people feel safe to take risks and get feedback, and not be scared to get negative feedback or try something different. Every team needs to start with figuring out how to build that trusting environment among other collaborators so that kind of bleeds through all the work that you do together,” Atlassian’s Colli added. 

The post The art of code reviews appeared first on SD Times.

Using Code With Me, team members will be able to quickly access others’ code to help investigate issues, review, and work on your code together. Other IntelliJ IDEA features like code completion, smart navigation, refactoring, the built-in terminal, and the debugging suite, are all available while using Code With Me. 

Example use cases for Code With Me include pair programming, mentoring, and swam programming, which is when developers simultaneously code together in a single IDE, JetBrains explained. 

Currently, 20 developers including the host can participate in a single session, though active code editing is limited to five participants at a time. 

To participate in the EAP, developers can install the Code With Me plugin through the JetBrians Marketplace to the latest version of any JetBrains IDE.

According to JetBrains, Code With Me is expected to be released with one of the upcoming major releases of JetBrains IDEs, though a date has not yet been set. 

The post JetBrains launches Code With Me EAP for distributed collaboration appeared first on SD Times.

According to Microsoft, Bosque derives from a combination of TypeScript inspired syntax and types plus ML and Node/JavaScript inspired semantics. 

The language was created to simultaneously support a high productivity development experience that  modern cloud developers expect, while also providing a resource efficient and predictable runtime with a performance profile similar to a native C++ application.

“The move into cloud based development, with architectures based around microservices, serverless functions, and RESTful APIs, brings new challenges for development. In this environment an program may interoperate with many other (remote) services which are maintained by different teams (and maybe implemented in different languages),” Microsoft wrote in a blog post. “The Bosque project takes a cloud and IoT first view of programming languages. Thus, it includes features like API Types to simplify the construction and deployment of REST style APIs.”

The combination of choices such as fully determinized language semantics, keys and ordering, and memory behavior result in a runtime with minimal performance variability and to enable ultra-low overhead tracing, according to Microsoft. 

The main features of the language include immutable values, block scoping – which is very appealing for structuring code according to Microsoft -, named arguments along with rest and spread operators that can be used to perform simple and powerful data manipulation as part of invocations and constructor operations. 

“Bosque is about connecting a constrained core-language IRs to a developer friendly and high-productivity programming experiences,” said Mark Marron, a principal research software development engineer (SDE) at Microsoft Research in the webinar Expanding the possibilities of programming languages with Bosque. 

The Bosque language also includes reference parameter threading via ‘ref’ argument passing, an alternative to multi-return values that simplifies scenarios where a variable is passed to a method. In addition, it provides two flavors of typed strings, ‘SafeString<T>’ and ‘StringOf<T>,’ to address various scenarios where including meta-data about the string in the type is useful.

“If you’re going to upgrade a dependency, you can check if it is possible that this new dependency is going to change the behavior of your application somewhere and allow you to do version upgrades much more quickly and confidently,” Marron said. 

Marron added that one limitation that Bosque currently has is that there is currently no IO support or runtime, but Microsoft Research is working with Morgan Stanley to integrate Bosque and use their runtime.

Additional details about the Bosque programming language are available here.

The post Microsoft provides insight into its programming language Bosque appeared first on SD Times.