Posted by: lrrp | October 4, 2022

Java Features After Java 8

After Java 8, Java 9 has big changes & new features. Here in this section, we will talk about Java Features After Java 8. If you are preparing for a Java developer interview, there are 100% chances that, you will find some questions about this topic. This article may work as a refresher for the interview.

You can learn about Java 8 Features from a separate article. We will update this section on a regular basis in case of a release of the new version. Let’s see Java Features After Java 8.

New In Java 9

Let’s start our topic ‘Java Features After Java 8’ with New Features in Java 9.

1) Java Platform Module System: Jigsaw Project
2) JShell Command Line Tool
3) Private Methods in Interfaces
4) Diamond Operator Extension
5) Improvements in Stream API
6) Introduction of  Factory Method of() for creating a Collection.
7) Small Modifications in Try-With-Resources
8) Мulti-Resolution Image API
9) HTTP 2 Client ( A new Client)
10) Platform and JVM Logging
11) Process API Updates
12) Multi-release JAR Files
13) @Deprecated Tag Changes
14) Stack Walking

New In Java 10 

1. Local Variable Type Inference : var x=10; allowed but var is not a keyword

var map= new HashMap<String,List<String>>(); is valid
var stream =List.stream(); is valid
var path = Paths.get(filename); is valid
var numbers= List.of(1, 4.5,”Java”); is valid

var s =null is not allowed.
var can’t be defined at class level, can’t be assigned to Lambda expression but can be defined inside lambda expression.

2. java.util.stream.Collectors has new method Collectors.unmodifiableList() to control list from modification. Similarly for Set & Map as well.

java.util.List, java.util.Map and java.util.Set each got a new static method copyOf(Collection). It returns the unmodifiable copy of the given Collection. An attempt to modify such a collection would result in java.lang.UnsupportedOperationException runtime exception.

3. Optional.orElseThrow() : 

java.util.Optionaljava.util.OptionalDoublejava.util.OptionalInt and java.util.OptionalLong, each got a new method orElseThrow() which doesn’t take any argument and throws NoSuchElementException if no value is present:

4. Garbage collector changes
5. Some methods are deprecated.

Note: Java 10 was the last free Oracle JDK release that we could use commercially without a license. Starting with Java 11, there’s no free long-term support (LTS) from Oracle.

New In Java 11

Note that from Java 11 Oracle has updated the license term to use only for developing, testing, prototyping, and demonstrating your application. You may not use the programs for data processing or any commercial, production or any internal business purposes.
The subscription plan was already in place on a yearly or one-time payment basis but they have given the option of a monthly subscription now.
In summary, Java is free for personal & non-commercial use always.

Added Features:

1. Collection.toArray(IntFunction) default method : The java.util.Collection interface got a new default toArray() method which takes an IntFunction argument in order to make it easier to create an array of the right type from a collection.

2. Local-variable syntax for Lambda Parameters : Usage of var keyword in lambda parameters started from Java 11.

3. Some new methods to the String class: isBlank()lines()strip()stripLeading()stripTrailing(), and repeat(). Undoubtedly, these methods will minimize the amount of boilerplate code used in the manipulation of string objects, and save developers from importing various libraries.

4. New File Methods : Files class got new static methods readString() and writeString() in order to read and write Strings from files.

5. The ‘not()’ Predicate Method: The Predicate Interface has got a static not() method to negate an existing predicate.

6. Running Java source File directly without compile :  Starting from Java 11, we don’t need to compile the Java source files with javac explicitly anymoreInstead, we can directly run the file using the java command.

Removed features :

1. Com.sun.awt.AWTUtilities class: it was deprecated since jdk8
2. appletViewer Launcher
3. Thread.destroy() & Thread.stop(Throwable)
4. Java EE & CORBA modules

New In Java 12

1. Switch-case Statement : multiple entries allowed as case input

String input=”Monday”;
switch(input) {
case “Monday”, "Tuesday”,”Wednesday”, “Thursday”, “Friday” ->System.out.println(“Week days”);
case “Saturday”, “Sunday” -> System.out.println(“Weekends”);
default -> System.out.println(“Invalid days”);
}

2. String literal: HTML code can also be included without any \n character.

String html= “<html>
<body>
<p>Hello World.</p>
</body>
</html>”;

3. String Class new Methods : indent() and transform()

indent() method is used to adjust the indentation of each line on the basis of the integer parameter passed to it. If the parameter is a positive integer (greater than zero), new spaces will be inserted at the beginning of each line. On the other hand, if the parameter is a negative integer (less than zero), it removes spaces from the begging of each line.

transform() accepts a single argument function as a parameter that will be applied to the string.

4. File mismatch() method: The nio.file.Files utility class has got a new mismatch() method in order to compare two files and find the position of the first mismatched byte in their contents.

5. Other Garbage Collector & Performance Improvements

New In Java 13 

In continuation to ‘Java Features After Java 8’, it’s time to talk about new features in Java 13.

1. Yield keyword in Switch-case Statement: If we use the colon (:) operator, we need to use the yield keyword as shown in below code snippet.

String input=”Monday”;
switch(input) {
case “Monday”, "Tuesday”,”Wednesday”, “Thursday”, “Friday” : yield System.out.println(“Week days”);
case “Saturday”, “Sunday” : yield System.out.println(“Weekends”);
default : yield System.out.println(“Invalid days”);
}

2. Text block: will be printed exactly as it is written: introduced with triple quote “”” . Now JSON format code can also be inserted without any special character.

String html= “””<html>
<body>
<p>Hello World.</p>
</body>
</html>”””;

3. Other performance-related changes

New In Java 14

Please visit Java 14 Features

New In Java 15

Please visit Java 15 Features

New In Java 16

Vector API
Enable C++14 Language Features
Migrate from Mercurial to Git
Migrate to GitHub
Concurrent Thread-Stack Processing
Unix-Domain Socket Channels
Alpine Linux Port
Elastic Metaspace
Windows/AArch64 Port

New In Java 17

Restore Always-Strict Floating-Point Semantics
Enhanced Pseudo-Random Number Generators
New macOS Rendering Pipeline
macOS/AArch64 Port
Deprecate the Applet API for Removal
Strongly Encapsulate JDK Internals
Pattern Matching for switch

New In Java 18

UTF-8 by Default
Simple Web Server
Code Snippets in Java API Doc
Reimplement Core Reflection with Method Handles
Vector API
Internet-Address Resolution SPI
Foreign Function & Memory API
Pattern Matching for switch

New In Java 19

New System Properties for System. out and System. err
Additional Date-Time Formats
New Methods to Create Preallocated HashMaps and HashSets
Windows KeyStore Updated to Include Access to the Local Machine Location
Support Unicode 14.0
Automatic Generation of the CDS Archive
Support for PAC-RET Protection on Linux/AArch64
HTTPS Channel Binding Support for Java GSS/Kerberos
Add a -providerPath Option to jarsigner
New Options for ktab to Provide Non-Default Salt

Deprecated Features & Options In Java 19

java.lang.ThreadGroup Is degraded (Under core-libs/java.lang)
Deprecation of Locale Class Constructors (Under core-libs/java.util:i18n)
PSSParameterSpec(int) Constructor and DEFAULT Static Constant Are Deprecated (Under security-libs/java.security)
OAEPParameterSpec.DEFAULT Static Constant Is Deprecated (Under security-libs/javax.crypto)

We will extend our topic ‘Java Features After Java 8’ with further explanation of existing facts when necessary.

Advertisement

During development, the code tends to be long. At some point, the codebase becomes so bloated that you can’t handle it. Nevertheless, senior developers make things work somehow. How do they do that? “All enterprise level developers actively use interfaces”. So today, I am going to explain Interface Segregation Principle in one of SOL’I’D PRINCIPLE. If you didn’t know this, you should know that you are falling behind.

What is Interface Segregation Interface?

No client should be forced to depend on methods it does not use

Interface Segregation Principe is also called ISP for abbreviation. When you write code, it’s pretty easy to violate ISP, because your software evolves and you have to add more features. The aim of ISP is to minimize the side effects by splitting the software into independent parts. The point is “YOU SHOULD ONLY DEFINE METHODS THAT ARE GOING TO BE USED”.

Bad Practices

interface IMultiFunction {
    public void print();
    public void getPrintSpoolDetails();
    public void scan();
    public void scanPhoto();
    public void fax();
    public void internetFax();
}

What do you think? Do you think the code example above has nothing wrong?

Firstly, you need to ask yourself if the methods defined inside IMultiFunction is cohesive. Obviously, print() and getPrintSpoolDetails() are cohesive. But how about print() and scan() ? Do all printing machines support these features?

I’m going to show you another example.

class CanonPrinter implements IMultiFunction {

    @Override
    public void print() {}

    @Override
    public void getPrintSpoolDetails() {}

    /* This machine can't scan */
    @Override
    public void scan() {}

    /* This machine can't scan photo */
    @Override
    public void scanPhoto() {}

    /* This machine can't fax */
    @Override
    public void fax() {}

     /* This machine can't fax on internet */
    @Override
    public void internetFax() {}

}

CanonPrinter can’t fax. But it still needs to implement fax().

In software development, Unimplemented methods are almost always indicative of a poor design.”

So, what should you do?

Good Practices

ISP starts by splitting big interfaces into smaller interfaces.

Let’s refactor!

interface IPrint {
    public void print();
    public void getPrintSpoolDetails();
}

interface IScan {
    public void scan();
    public void scanPhoto();
}

interface IFax {
    public void fax();
    public void internetFax();
}

This is a much better approach. Not only did you split big interfaces into smaller interfaces, it has also nicely defined functionalities that also satisfy the Single Responsibility Principle.

class HPPrintNScanner implements IPrint, IScan {

    @Override
    public void scan() {
        // TODO Auto-generated method stub
        
    }

    @Override
    public void scanPhoto() {
        // TODO Auto-generated method stub
        
    }

    @Override
    public void print() {
        // TODO Auto-generated method stub
        
    }

    @Override
    public void getPrintSpoolDetails() {
        // TODO Auto-generated method stub
        
    }

}

As you can see, HPPrintNScanner implemented only necessary methods.

Techniques to identify violations

  1. Find if your Interfaces have methods with low cohesion
  2. Check Empty Method Implementations

Conclusion

You’ve learned some great techniques that will increase the quality of your code. This is one step closer to making a scalable application. Go practice practice practice!

Posted by: lrrp | July 7, 2022

The Power Of Deep Work For Developers

And how it helped me become a Senior Developer fast.

Every day, ask yourself, to “evolve or repeat?”

I have decided to take on a break, I needed to think about a lot of things and also to be able to focus on just one thing which is programming.

And a little update, it was fulfilling, probably one of the most productive times in my programming career, I had been able to push my limits, and have been rewarded for it.

Finally, with all the skills I have learned over the past years, especially since the start of the pandemic, where I had the opportunity to get as much time as I can in front of the screen because of the isolation and no commute.

I also had the best excuse to say no to any gatherings, so I can solely focus on pushing myself and chasing my dream of becoming a Senior Full-Stack Developer.

I’d say I have fully embraced it, I was also lucky enough to be able to work as a Core Developer in this HUGE project that we’re currently working on, and when I say huge I mean a project that will accommodate millions of users.

The power of deep work

I have used this concept several times, and as living proof, all of my success was a result of preaching this.

Just recently I did what I needed to do, the project I have been currently working on is just so difficult that I needed to make a lot of sacrifices.

Deep work is a practice wherein you need to eliminate unnecessary things, even some necessary things, to achieve your main goal.

I have spent the past 9 months focusing on programming, giving my heart out just to help push this project forward.

It isn’t just about spending 10hrs on the computer, if it’s that easy anyone can do that, but deep work will require a lot from you, it is like surrendering yourself, letting your mind flow in the river, and doing your best to stay in that zone for as long as you can.

Once you are in the zone when you get there, it’s like magic, all the data, the process, the system flow, the other “connected” data, the model, the idea or feedback from your colleagues, and the processes are all in that same room wherein you can analyze, you can design, especially and most importantly when you are debugging.

Finding the bug, the cause, the solution, and everyone involved in that same room of yours inside your brain, It’s just magical.

In the past few months, I have solved so many bugs, I had able to find solutions and preventions to a lot of things, especially in the module that I am handling.

I now handle 20+ developers under my wing, it isn’t easy but as time goes I had able to manage them well, it was so stressful, but it is a great experience, and being able to do what I love and getting rewarded for it is priceless.

How to sustain it

You should embrace this practice or technique, it will take time, it will take several practices, you will fail, and you will try again, you need to be practical and realistic, obviously you cannot do the magic when there are thousands of distractions in your environment.

You cannot do deep work while your phone is there next to you, you cannot deeply work when your kids are there in the same room as you, and you cannot deeply work if you only have an hour or so.

It’s common sense, you should design your environment to be workable, I mean how can you work when people behind you are walking and shouting, yes it makes sense if you use a headphone, it probably depends on how you handle things especially when you start working in the office.

My point is to make sure that you will avoid any distractions as possible, do not open your social media, put your phone away, and put a signboard on your back so no one will distract you because the point of this practice is to get in that zone and stay there for as long as you can.

You need to be patient, it will not come easily, but trust me, it is addicting, especially when you see the results.

The cost

There are several rules to using this technique:

  • Try to stay as focused as you can, you need to work deeply
  • Embrace boredom, accept it.
  • Toss your phone away, don’t you dare open your social media
  • Toss your kids away
  • Toss your partner away
  • Guide your grandma/grandad out of the room
  • Make sure everything is silent, no alarm clock, not a single sound

Getting in the zone is already hard enough, staying inside the zone is harder, so make sure no one or nothing can distract you while you’re in it.

You will lose some and gain some, and there will be sacrifices, but if something is important to you then you need to do what is necessary to achieve your goals.

Since I started programming I have lost a lot of people in my life, I have sacrificed my old life for my dream of becoming a developer, and as I move forward I started to dream big, getting that first job was only just the beginning.

I wanted to become a Full-stack developer, I had my plan that in the next 10 years I will get that full-stack job, but with luck hard work, and perseverance, I got that dream job after 5 years.

Fast-forward, I’ve been a developer for 6 years, almost 7, and that 10-year target I got at 5 (though at training), and now finally I am confident enough to call myself a full-stack developer, and now I am handling 20++ other developers working in my wing, life as a developer have never been this amazing.

For all these years, I have realized a lot, not just in my developer career, but in life in general — you see, you cannot build a new one without restructuring the old one, you will lose some and gain some.

You cannot achieve your dreams without sacrificing things, life will hit you in the head with a brick, you will fall more than you can count, life doesn’t hate you it is training you to be strong, tough, and persevere.

Life is never fair, but every day you have a choice to evolve or repeat, so ask yourself every morning, do you want to evolve? Or do you want to repeat your life every single day? The choice is always up to you.

You might be born in poverty, or the middle class, that’s not your fault, but what comes afterward once you start to develop common sense is completely your responsibility, so whether you choose to live life as a victim of society then so be it.

The point is, you have a choice, so make sure you choose your life and the way you want it to be.

The reward

The journey was the reward itself, to be honest, I never thought self-taught development is possible, I didn’t know it was achievable until I got that first job, the journey was harder than I imagined, I almost quit several times, I cried, I got myself in trouble more than I can count.

I got humiliated, but one thing that saved me was my mindset that whatever happens, I will just keep showing up.

Regardless of how stupid I looked like working alongside those computer science and computer engineers, I may be the most stupid person in the room who cares, I was in the right room all along, and now almost 7 years, life has never been rewarding.

I’m right here living my best life, and I want that for you too, you are me years ago, and I am you in the next years ahead, so whatever happens keep showing up, and remember you always have a choice, I hope you choose your best life.

Just stay patient and keep going.

Posted by: lrrp | July 7, 2022

How to Be a Good Leader in Really Bad Times

Try these techniques to help your team stay sane and focused despite the parade of horrible headlines.

When a team led by a Harvard researcher studied the psychological impact of negative news recently, it came to a startling conclusion. Just three minutes spent scanning grim news in the morning increased the chances a person would be in a bad mood six hours later by 27 percent. Even tiny doses of bad news have long-lasting, negative impacts on our psychology

This is particularly troubling considering how much bad news we’ve had lately. After more than two years of plague, 2022 has served up war, famine, a series of climate disasters, regular mass murder, and the very worst forms of political division. Sometimes it’s easy to mistake your morning newspaper for the scarier sections of Revelations. 

Coping with this avalanche of bad news is a challenge to the mental health of us all (not to mention the health of the republic and the planet… but that’s a different column). But it’s also a particular challenge to business leaders given just how distracting and depressing research shows negative headlines to be. How do you process your own pain and confusion while helping your team stay sane and, ideally, also get some work done? How do you balance compassion and business objectives? 

These aren’t issued traditional business education much prepares you for, but expert help is available. A recent HBR piece by former Harvard dean turned coach Mollie West Duffy and Liz Fosslien, head of communications at Humu, offered advice on how to be a good boss in terrible times. The complete piece is well worth a read, but I’ve boiled down three of the most important takeaways below. 

1. Start before the next tragedy. 

Your efforts at keeping morale up in challenging times can’t start after the latest horrifying headline. You need to win trust before tragedy strikes. “You can’t expect employees to feel safe opening up… if you’ve never previously made an effort to ensure they feel comfortable having identity-based discussions,” West Duffy and Fosslein write. 

That doesn’t necessarily mean debating politics and identity at work. What it does mean is making sure employees feel comfortable bringing their whole selves to work. Whether your employees spent their weekend at a church potluck dinner, marching in their local gay pride parade, or volunteering for their favorite cause, they should feel comfortable talking about it around the office (or on a videoconference) on Monday. 

“If I don’t feel comfortable telling you about these things that I do in my off time, or things that are connected to my identity, then how am I going to feel comfortable telling you when things are bad?” Angelica Leigh, a professor who studies diversity asks in the article. 

2. Acknowledge the awfulness. 

When the world seems like one giant dumpster fire, it can be tempting to try and seal your team off from the flames behind a protective wall of silence. But ignoring terrible news doesn’t boost productivity. It just makes you look clueless or cruel. 

“If you say nothing, your team will assume you either don’t know or don’t care about world events–which will erode trust,” the pair warn. Depending on the size of your team, either gather them together or send an email to address whatever is new and horrible. 

What should you say? That depends on both who you are (be authentic) and what the latest event is. But West Duffy and Fosslein suggest two guiding principles–“communicate like a human and from the heart” and “provide a path forward.” 

“That might mean creating an opt-in space for people to process their emotions… offering employees paid time off if they need it, or sharing other resources or company policies that might be helpful during a time of crisis,” they explain. 

3. Help each employee to process in their own way.  

When faced with horrible news, some people distract themselves with work. Others reach out to trusted friends to process their emotions. Still, others only feel better when they’re taking positive action to effect change. Don’t put people on the spot or dictate how they respond, but do offer them space to process in their own way. 

That might mean having a relevant employee resource group host a discussion, loosening expectations for a few days while people come to terms with whatever has happened, or working with an employee to re-prioritize their schedule to create some more breathing room. If appropriate, it also could mean organizing a volunteer opportunity or fundraising drive to channel employees’ desire to take action. 

Whatever steps you end up taking, communicate that you’re there for your team. “Make it clear that your door is always open,” the authors advise. “You might say something like, ‘In light of ______, I want to reiterate that if there is anything I or the organization can do to help you in the coming weeks, do not hesitate to let me know. And if you need to take time to decompress, please do so.'”

These steps are, of course, not a complete answer to the fraught but important question of how business leaders should respond to the challenges we face. When and how to take a stand is a question for a much longer article than this. But while you’re pondering your responsibilities don’t neglect essential psychological first aid for your team. Ignoring horrible things doesn’t make them go away. Acknowledging reality and offering human support and connection will help, however. 

Posted by: lrrp | July 5, 2022

5 Ways to Deal With Difficult Employees

You cannot ignore toxic coworkers as they cause trouble for you and your team culture. Always call for a change.

What is important to you at work?

You may wish for supportive coworkers and pleasant team culture. Although it sounds normal, it is far from that. I bet you have had at least one problematic or even toxic colleague.

One person can have a terrible influence on your team. The earlier you recognize that something is not working, the better chance you have of fixing it before it becomes a serious problem.

You cannot ignore what is happening on the team. Have a clear idea of what values you want people to align with and talk openly with them.

1. Don’t look away

I had a colleague who was a mess. He was making such a fuss about everything. He was not a team player and was a bit of a narcissist. Yet, he was also very effective with clients and got a lot of business in.

Our manager chose to look away. When you look away, you decide to tolerate the situation.

This troublemaker bullied the whole team. He did not help with anything. He chose not to share any knowledge with the rest. When we complained separately to our manager, she promised to speak to him.

Yet, nothing has changed in 1.5 years. The team was demotivated, and some thought about leaving. Then the manager changed and fired this guy for the sake of team health.

You should never ignore the tension in the team. Not even when you think that you cannot lose a high-performer. You have a team for a reason. When one part does not work, the whole team is impacted.

Cultivate social sensitivity. If your feedback is ignored, choose stricter tools. The ideal solution to do is to consult with other managers and HR about what can be done.

2. Listen fairly and experiment

In your management career, you have a lot of conflicts. Some team members cannot work together. Personalities clashes are normal.

I had two colleagues who hated each other. One was detail-oriented and strict. The other one was a creative guy living in his world. They drove each other nuts. Both of them spoke to me and put a lot of dirt on each other. So, where was the truth?

Always listen to both sides without preference. You may like one coworker more than the other, but be fair. Listen to each part of the story. Collect as much information as you can before deciding on a solution.

In my case, I tested both by letting other people work with them. This experiment revealed that the creative mind was not diligent with his work and did not care about the outcome. So, moving him to a different colleague helped him to understand what performance was needed, and that it was not only because one coworker was strict.

3. Be open about your emotions

You may hesitate to talk about how you feel when you are in a leadership position. You do not want to look weak. I get it. But to be fair, there is nothing wrong with sharing your feelings.

Your feelings reflect the situation in your team. How does it feel?

I was once led by a very insecure manager. He did not want to hurt anyone. Yet, his team suffered from his lack of decision-making power and hesitation. He seemed to ignore training and coaching tips.

So what now?

What worked, in this case, was to openly discuss our frustrations. Many times, the problem is the lack of communication and understanding. When you open up, you may find similarities.

We found out what was overwhelming for the manager and created a step-by-step process for him. I also understood I wanted a lot from him while his willingness to adapt was slower. At the end of the day, he got better and earned the trust of his team.

4. Be time-sensitive

I have seen many managers making this mistake. They were too patient and hopeful. They believed people could change by reminding them several times of the same issues. Yes and no.

People can change if they want to. Yet, many toxic employees do not want to. They are convinced they know the truth, and the rest is wrong. This false idea is very problematic. It touches on the topic of who is a real victim.

My brand-new team member was lost. She said the other colleagues did not explain to her how to do things. They said she did not listen to them. They argued a lot and became annoyed. I facilitated this conflict by calming both sides and creating an action plan for training.

The training was progressing, but the complaining colleague did not. She said she needed more time. I gave her more time again and again. Until we realized how much time we spent.

Patience is a virtue. But it is not neverending. Be generous but realistic. Any action plan needs a schedule and clear consequences for what happens when it is not met. Yes, people may need to leave if they do not perform well. That is how it is. The sooner you accept it, the better manager you become.

5. Do not deal with it alone

You have to invest a lot of emotional and mental energy into dealing with difficult employees. It is tiring and difficult to let go. So, why would you act as a solo knight in this situation?

Can you save the world? Probably you can. But not alone.

Find your allies. Your manager, fellow managers, and HR representatives can help you. In addition to sharing their experience, they can advise on steps you can take from a legal and company policy perspective. Always make sure you know what you can or cannot do.

Respect employee rights, always.

Sometimes managers don’t want to share the problems of their teams for fear of looking incompetent. If managers cannot speak together, it shows how dysfunctional the whole culture is. Call for a change.

If you work in a toxic environment, it’s no surprise that your employees are also difficult. Consider the situation carefully and decide what to do. Sometimes it is not about individuals, but about shifting the whole culture.

Final Thought

Be present in your team. Listen carefully to complaints and feedback. When you see a problem early, it is so much easier to deal with it. Always call for a change before your team is emotionally involved and drained.

I am in favor of time-sensitive experiments within legal and company policies. A lot of tension comes from people not understanding each other. Their communication is blocked. You can help them if the culture is trustworthy and supportive.

Experience is valuable. But for startups? I don’t think so

Running a startup is exciting. You are part of a journey where the destination moves constantly.

Hiring and managing people is even more challenging. A well-organized team is the most important asset for a startup.

In my experience as a founding member of a startup — and after working for multiple startups in the last 3-4 years — I have noticed that the outcome of a team depends more on chemistry than technical strength.

Today, I will share my experience with older programmers and why I think startups should avoid hiring them.

They Have More To Lose

Younger programmers are eager to take risks. They have nothing to lose. They can bet on a promising technology or change to a different tech stack.

But the case is different for older programmers. They have spent their career working on a specific technology. Maybe they are very good at it, but it’s not guaranteed that technology will solve every problem.

In these scenarios, they oppose adopting a new technology because they suddenly go from experts to newbies!

In one job, I had a hard time convincing my boss that React was a good choice instead of JSP for a frontend application because he was a Java developer and wasn’t willing to learn React!

They Are Too Technical

Being technically perfect is not bad — especially when you have a lot of time. But getting things done out of the gate is the #1 priority for most startups.

As a startup, you have to try out many things. You don’t even know if the feature you are building right now will be in the final product at all.

But older programmers often care so much about the technical nitty-gritty that it becomes impossible to get things done.

Obviously, the scenario is different when a team is working on an established product. Achieving high quality is mandatory there.

They Are Sometimes Political

It’s obvious. When someone is starting as a junior or even mid-level developer, their primary focus often is to improve their skills. They know there is room to grow and they are eager to do so.

They enjoy their time learning new tech and talking with like-minded people.

But as devs grow older, they get involved with a lot of things. It becomes harder to distinguish them from business people. I don’t think that’s necessarily a bad thing. It’s even required in some cases

But in startups, most of the time, integrity and friendliness are the main traits in demand. A business-type mentality can create conflict among other developers.

They Are Often Outdated

We all have our choice of technology. We try out many things but stick to particular ones all the time. Programmers are biased people.

For example, I love working with React. I am aware of the fact that it will not remain as popular as now in 20 years.

But will my older self be able to switch to another new language that easily? Will I have that energy, courage, and time?

Probably not.

That’s exactly why older bosses often try to impose their technology of choice on junior devs. That’s why they have to do some pretty weird stuff.

I had to serve a React application bundled inside a Spring Boot application just because our backend apps were written in Java.

The logic was “That’s how we do it here. Can you argue with that?”

Final Thoughts

I am aware of the value that experienced programmers bring to the table. And for the system- and architecture-level design, you should have someone who has been doing this for a long time.

They can also do a decent job of managing people, but when it comes to technical jobs, it can backfire.

For enterprises, the case is certainly different. Older programmers should be there because they have more experience with handling tough situations. But for startups, it is not the same.

Posted by: lrrp | October 28, 2021

9 Habits I Wish I Had as a Junior Developer

Have you ever sat down and taken an inventory of your habits? Habits are what make us who we are.

Good habits help you to become who you want to be. Bad habits will slowly turn you into someone you don’t want to be.
After more than 20 years as a software developer, I’ve grown some habits that I’m proud of and some that I’d rather get rid of.

Most of the time, I wasn’t aware of my habits, but looking back, it’s pretty clear to me which habits were helping me grow and which were hindering me. This drove me to take an inventory and write about good developer habits to maybe inspire you to do the same.

If you’re starting as a developer, have a look at the habits outlined below and ask yourself if they would help you become who you want to be. Be conscious of your habits and actively nurture them to become a great software developer.

Volunteer for Things You Don’t Know

At the start of your career, you don’t know a lot. You come into that new project and feel like an impostor because they’re paying you money even though you don’t understand half of the acronyms, technologies, and frameworks they’re throwing around in each meeting.

And you only faintly know the other half because you googled them.

Replace “At the start of your career” with “At the start of any new project”, and you have a pretty good summary of a software development career. Every new project, we start over. There are new people to meet, new requirements to understand, and new frameworks to learn. Every single time.

This is why it’s important to learn new stuff. If you just keep doing the things you know, you’ll never be confident about starting a new project. There will always be the fear of the unknown. If you make it a habit to volunteer for tasks you don’t know anything about, you will constantly learn new things.

If the build needs fixing and you’ve never worked with the build system, get on it! You’ll learn about build management. If there’s a bug in the JavaScript frontend and you’ve only worked on the Java backend so far, fix it! You’ll learn new Javascript idioms.

Doing stuff you’re not confident about doing is a great way to grow. Be sure to manage other people’s expectations towards you, though. Don’t pretend you’re an ace. Tell them you haven’t done it before but you would like to learn.

Ask to Pair Up
If you’re stuck and can’t get started with a task because you’re unfamiliar with the context, ask someone with experience in the topic to pair up with you.

A pairing session is a great way to kick off the work on a task. Discuss the requirements with your partner until you have an understanding of what is expected. Then, discuss the solution.

What’s the context? Which codebase(s) do you have to touch? What are the explicit and implicit conventions in the codebase?

But you can make pairing even further. Instead of just pairing up to kick off a task, schedule more time with your partner. After kicking off the topic, start working on it together. You drive, your partner gives advice, then the other way around.

This way, you even get to learn how your partner thinks and solves problems. You can only profit from it! Even if it’s just a new IDE shortcut you learned.

A note on working from home: due to working from home, I struggled with things that would not have been a problem before. I hesitated to ask teammates to pair up with me. What was a simple tap on a teammate’s shoulder in the office became a high barrier when working remotely and communicating with video conferencing software.

If that is a problem in your team, talk about it with your teammates (in a retro, for example) and it will be much easier afterward. Turns out it’s just a habit to re-learn.

Ask to Pair Up

If you’re stuck and can’t get started with a task because you’re unfamiliar with the context, ask someone with experience in the topic to pair up with you. A pairing session is a great way to kick off the work on a task. Discuss the requirements with your partner until you have an understanding of what is expected. Then, discuss the solution.

What’s the context? Which codebase(s) do you have to touch? What are the explicit and implicit conventions in the codebase?

But you can take pairing even further. Instead of just pairing up to kick off a task, schedule more time with your partner. After kicking off the topic, start working on it together. You drive, your partner gives advice, then the other way around. This way, you even get to learn how your partner thinks and solves problems. You can only profit from it! Even if it’s just a new IDE shortcut you learned.

A note on working from home: due to working from home, I struggled with things that would not have been a problem before. I hesitated to ask teammates to pair up with me. What was a simple tap on a teammate’s shoulder in the office became a high barrier when working remotely and communicating with video conferencing software. If that is a problem in your team, talk about it with your teammates (in a retro, for example) and it will be much easier afterward. Turns out it’s just a habit to re-learn.

Talk about What You’re Doing (and What You’re Not Doing)

I don’t remember how often I have eagerly taken on a task, thinking I’d be done within a day, but I end up still working on it a week later. It gets better with experience, but I still find myself making too optimistic estimations. There are just too many reasons to make an optimistic estimation:

the pressure to deliver this new feature quickly because the deadline is looming,
the pressure to look good among peers,
things just not working as I expect them to (this is the one that’s most commonly throwing me off, even with years of experience),
and a lot more .

Chances are that most of your estimations end up being too optimistic. What can you do about that?

You can manage expectations along the way.

Continuously talk about what you’re doing and what is holding you up. With “continuously” I don’t mean that you should provide a status update to the whole team every 15 minutes. But make sure the relevant people know where you stand at the start or the end of the day, at least.

So, if your manager / team / project manager / product manager / stakeholder expects results from you, give them a quick update every day: “This is what I’ve been doing. This is the next step. This is a problem I’m facing. These are the options.”

This will let everyone know of your progress. No one will blame you if you’re hitting a wall, as long as you kept them in the loop.

This will make discussions of the type “Why did that take so long?” a thing of the past. As an added benefit, the status update will trigger discussions that can help solve problems. In the best case, this status update is ritualized in the team. It’s commonly called “daily standup” where every team member quickly updates the rest of the team about their progress and problems.

But even if you have a daily ritual like that, take a couple of minutes to think if anyone should be updated that is not part of the daily ritual. Should they be included? Or should they be updated through some other mechanism?

Make it a habit to regularly update the people that have an interest in the results of your work.

Write a Blog

I’m probably not the first person you’ve heard saying this, but I’ll say it nevertheless: write a blog!

It doesn’t even have to be public. It can be a couple of pages in a company wiki or a collection of GitHub repositories with example code and a couple of lines of explanatory text.

Why?

Because writing with the intention to teach others (even if it’s just future you) is a great way of learning and growing.

Write about how you solved a gnarly problem. Write about how to use that new and shiny framework you always wanted to try. Or write a journal of what you did each week (this will also help with the “talking about what you’re doing” habit because you can look up what you’ve been doing).

I have started a blog a couple of times. It’s hard to keep the motivation up in the beginning, because no one will read your blog posts. It feels strange to write into a void. So I stopped. Then, I started my current blog 3 years ago, writing without an audience for half a year. I noticed only then that my robots.txt file didn’t allow search engines to index my blog!

So I changed my robots.txt file and people actually started to read my stuff. Not many, but it gave me the motivation to continue. So, I pulled through, tuned my writing skills along the way, and grew my blog to > 200,000 page views a month.

All because I started writing about frameworks I wanted to learn and problems I had solved so that I could look my articles up again when I needed them. Not because I wanted to create a big audience. Blogging is a chore at first but can grow to be very rewarding if you stick to it. If you do it with the intention of learning and teaching, you will not only learn a lot, but other people will notice your blog eventually and it will open a whole world of opportunities.

Have a Notebook and a System

I’ve only recently grown to be a big fan of notebooks. Not a computer notebook, but a real, paper notebook. I take it (and a pen!) wherever I go, so I can take notes about whatever strikes me as important at any time.I take notes when I listen to a talk, or when I’m waiting for the bus, thinking about what I could make for dinner this week.

I also use the notebook to maintain lists: books I want to read, frameworks I want to try out, features I want to add to my side projects. Most importantly, I use it to take notes while reading books, because that conserves the learnings from the book.

I’m writing down everything that weighs on my mind. If I don’t write it down, it will keep my mind busy, sometimes to the extent that I’m getting anxious and have trouble sleeping. The reason I’m getting anxious without my notebook is that I don’t trust my memory. If you have a great memory and can recall everything that you have thought about a week ago, you probably don’t need a notebook. If your memory is as patchy as mine, though, it will make a world of a difference to your peace of mind.

To build trust in your notebook, you need a system. You need to convince your mind that whatever you put into the notebook will not be lost. Create an index on the first couple of pages of the notebook to make the information retrievable. Then, make it a habit to review your notes regularly and process them.

To process the notes I’m taking while reading a book, for instance, I review the notes whenever I’m done with the book and write a book review on my blog. Almost no one reads these reviews, but the process of writing the review makes the things I learned stick so much better.

Keep Notes about Your Wins
Having a notebook can also help with the next habit: documenting your achievements.

As I said, my memory is patchy at the best of times. I can usually remember what I had for lunch yesterday, but if I’m deep in focus and spending brain power on some gnarly problem, the halftime of my memory goes down considerably.

That’s why I like to document my achievements at the end of the day. It’s usually not big achievements, but small wins – like having beaten a bug, or having finished one of the many steps towards adding a new feature to the software I’m working on. I also document personal wins like having stuck to my morning workout routine.

I just create a list of bullet points each evening in my notebook, but it’ll also work with a digital medium like a spreadsheet or whatever you’re most comfortable with – as long as you stick with it. Over time, the achievements aggregate. You might want to mark the ones that are most important to you so you can easily find them later.

Then, on an occasion like a performance review, you go through that list, find the achievements that are relevant to that occasion, and list them out to prepare. Performance reviews always work out better when you’re prepared. Having a list of your achievements also helps in everyday situations to talk about what you’ve been doing (see habit “Talk about what you’re doing”).

Have a Time Slot for Important Tasks

At the end of the day, I often feel I haven’t accomplished anything. While it helps to document your wins or even just the things you did, you still need to actually do those things. It happens quickly that you go from meeting to meeting and suddenly the day is over. After a meeting, you want to continue the task you started before the meeting, but just when you’ve warmed up, the next meeting starts. And after that meeting, you have to start over, because you lost the context.

Context switching is killing productivity.

If there’s one thing I learned to be productive, it’s having a dedicated time slot for things you want to get done. If you don’t have a pre-planned time slot for a task, chances are slim that you will get started on it. It will be eaten up by everyday work or other planned work.

There isn’t a single way to implement a time management habit, and, to be honest, I’m hopping from one productivity method to the next every couple of months. But the core is always the same: block some time in your day for the things you want to get done most. I block an hour in the morning, before work, to write articles for my blog (or for other blogs, like this one). Most days, I also block an hour in the evening, when the kids are in bed, to work on any side project I might have.

Currently, I have a Trello board with one column for every day of the week where I put the tasks I want to do in the morning and the evening. Once a week, I update that board with the things I want to do in the next week, so I don’t have to waste my precious blocked time thinking about what to do next.

I have a very similar Trello board for my software developer job. Every morning, I think of the things I want to do and put them into the column for the day. I also block at least 2 hours of focus time in my calendar every day, so that my co-workers don’t try to schedule any meetings at that time. That’s when I get through my list of tasks.

It doesn’t really matter how you manage your time, but it’s important to do it and to make it a habit. Otherwise, your days will be eaten up by things that are not important to you.

When Stuck, Take a Break

As software developers, we tend to get stuck a lot. And boy, does it piss me off when I’m stuck and don’t see a way out. It’s such obvious advice to take a break when you’re stuck, but it’s so hard to do. “I’m so close to solving the problem, I can’t take a break now!”

Also, taking a break now would mean I would have to warm up to the topic again later. Why should I deliberately switch contexts when context switching is the number one source of wasted time? When you’re stuck, you’re not thinking straight. You’re thinking about how stupid it is to be stuck with this problem, how easily your teammates would probably solve it, and why they always get the easy tasks. But you’re not thinking about how to solve the problem.

Take a break and work on something else for a time. Or even better, try again the next day. Getting some distance to the problem will allow you to see solutions you were blind to before. If you haven’t tried this before, you won’t believe how often a problem is “just solved” the next morning. Mostly because you see a path to a solution that you haven’t seen before.

Now, it’s easy to say to take a break, but how do you identify that you’re currently in “stuck mode” and then persuade yourself to quit working on the problem for a time?

I’m honestly not very good at this myself, because I usually WANT THIS DUMB TASK OUT OF THE WAY so I can show that I’ve achieved something! But what I found that helps me is to divide my day into 30-minute slices and have a quick recap after each of those slices. This technique is called the Pomodoro technique based on those tomato-shaped kitchen timers.

After each Pomodoro unit, I’m asking myself if I’m still working in a “solution mode”, or if I’m stuck and should work on something else for a while. A nice benefit of the Pomodoro technique is that you can use the end of a unit as a trigger for other habits.

I use it as a trigger to stand up from my chair to stretch my muscles and drink some water, for example. This is sometimes called “habit stacking”, because you’re stacking one habit on top of another, and it’s very effective. If you want to read more on habits, I can warmly recommend the book “Atomic Habits” by James Clear.

Don’t Chase Silver Bullets

I wrote a book on a specific architectural style and I regularly get emails saying “I love that architecture style and I want to apply it to all of my projects! How can I do that?”.

Can you guess my answer to that question?

There is no single architectural style that applies to all problems out there.

You build a plain CRUD API when it’s a small project. You build a more sophisticated Hexagonal Architecture if you have a complex domain model. And you apply any of a hundred different styles when you’re building microservices in a specific context.

Similarly, there is no single framework you should use for every single project. And there is no single best programming language or coding style.

Don’t fall for silver bullets. They don’t exist.

Having an opinion is good if it’s backed with good arguments. “This is the best architecture style” or “I’ve always done it like this” are not good arguments and people will see through them.

Just imagine you have a developer on your team that has an opinion on everything and always wants to do things their way, “because it’s the best way”. You would get tired of that very quickly. Don’t be that person.

Build Those Habits!

Wow, this article got longer than I expected. I hope it provided some inspiration on what to think about when growing your software developer career. I certainly haven’t mastered all of those habits, but I’m trying to get a bit better every day.

Pick the habit that resonates most with you and try to consciously apply it in your everyday work.

Meet Bob

Bob is an extremely ambitious and overachieving developer.

He works hard, refines his coding skills on a daily basis, and always finishes a project on or ahead of time — eager to get started on his next project. You can look at his code and immediately intuit that he’s a master at designing and architecting beautifully written code. He loves everything his job has to offer and because of that, he shows up every single day with an energy that allows him to pound out value like a machine. He feels on top of the world.

Bob is the quintessential programmer that many of us yearn to become. Surely, no one is more deserving of promotion than him? So, Bob was promoted to technical lead, a position that management thought he’d be even more valuable. Rightfully so.

But this also meant that he’d write less code and instead would have to focus more on managing the direction of the project as a whole. In other words, he’d have to do less of what he loved as a trade-off to do more of what he didn’t know how to do — managing others.

He lacked the ability to direct others, empathize with their schedules and knowledge, break tasks down for other people to succeed, and strategize for success. He expected everyone else on his team to be as good as he was as a programmer so he didn’t spend the time necessary to invest in their development — mostly because he couldn’t relate to their needs.

As the months went on, he proved to be less than capable of performing well in his new position. He had reached a brand new level of incompetence. His better nature and lack of managerial skills in his previous job led him to fail at what he did. This incompetence led his team’s productivity to plummet and their organization to crumble.

The Peter Principle

Bob’s situation is an all-too-familiar reality that many of us may recognize. I don’t know about you, but I’ve known a multitude of senior developers and technical leads who are absolutely terrible at doing what their job requires— leading. The sad thing is, these poor fellows were probably brilliant earlier in their careers. They have been pushed into a position they weren’t well equipped to thrive in.

This phenomenon is known as The Peter Principle:

In a hierarchy, every employee tends to rise to his level of incompetence. […] You will see that in every hierarchy the cream rises until it sours.

Although Laurence J. Peter wrote this bestselling idea as satire, it has proved to be unequivocally true — the idea that a person will be promoted again and again until they eventually reach their level of incompetence. For a developer, this can be mid-level, senior, lead, director, or all the way up to CTO.

As developers, it’s common to think that if you perform well and are constantly refining your coding skills, you’ll be promoted into a more prestigious position — one that bears far more responsibility and allows you to flex your merit and learned abilities. And that’s true — you most likely will be promoted. That’s the way things are.

People are generally promoted based on their performance in their current position, not because they hold the skillset necessary to fill the next position. It is merely assumed that they are more capable because of their past performance. Who knows, they probably are more capable.

Unfortunately, their capacity to do great things in the past doesn’t necessarily translate to their ability to accomplish great things in positions they fill in the future. For that, their promotion can serve to be a very poor investment in regard to the success of future projects. It’s a gamble, not a certainty.

That being said, in all likelihood, you’d probably be pretty awful as a manager. That’s not to hurt your feelings and undercut your abilities, but it’s because you’re so focused on your current job that you won’t be prepared for what the future holds.

Your own ambition is, paradoxically, a key that unlocks your own mediocrity.

You have the skills that make you great as a developer. You might even have the skills that make you a formidable team player. But you lack the skills that would make you great as a leader, architect, or coordinator. Programming alone doesn’t particularly develop those leadership-type attributes.

It’s for this very reason that so many incompetent people hold positions above us. This is why once brilliant people do horrible things. This is why certain projects go wrong under specific leadership. And no, it’s not the team who’s at fault — it’s the leader of the pack who failed to create an environment and organized structure for the team to succeed.

But it doesn’t have to be this way. You can’t transform the way your organization handles promotions, but you do have control over yourself and your own perception. You can harness your own unique ability to think and act.

Creative Incompetence : The Key to Being Good

Imposter syndrome is often seen as a bad thing. Of course, possessing the state of mind that you’re less competent than your job demands can cripple you. It could cause you to undersell yourself. When you deeply believe that you’re not capable, that often manifests as reality.

But there’s another way of viewing such a mode of thought — a psychological avenue that you can use to avoid falling victim to The Peter Principle. The adoption of “creative incompetence.”

Creative incompetence is similar to imposter syndrome in that you see yourself as incompetent. Except, you foster this mindset in an intentional way. When you intentionally view yourself as incompetent, you might ask yourself questions about how you might be able to alleviate such incompetence.

You prepare a strategy. You learn more than just what your job immediately demands of you. You refine your soft skills. You do what it takes to become more than a mere programmer. You take action to become someone dynamic enough to fill in future leadership positions within the realm of development that isn’t tied specifically to programming.

Remember, there’s far more to development than programming. In order to maintain yourself as a powerful asset in the long run, you have to prepare now. So, verse yourself not only in programming but in management, strategy, game theory, business philosophy, communication, and whatever else it is that will allow you to lead better.

You want to hit the ground running. If you think that because you succeeded in a past position, you’ll succeed in a future position, you’re in for a rude awakening.

“If you think you know everything; you know nothing. If you think you know nothing; you know something.” — Jayce O’Neil

So, be creatively incompetent. Believe that you know nothing. See yourself as incompetent.

Adopt this mindset as a means to better prepare yourself and motivate you to learn beyond what your craft currently demands of you and the future positions that you’ll need to fill. Be the developer in an idealized sense. This will allow you to continuously make an impact and improve without reaching a ceiling that limits your growth.

Posted by: lrrp | October 20, 2021

Why expert developers make the worst tech leads

‘A developer’s experience crafting code and designing algorithms does not prepare him or her for the unpredictable and highly emotional world of managing people’ Why expert developers make the worst tech leads image

All organisations with more than 50 employees will, at some point, require tech leads. Great tech leads can create a harmonious environment, where each team member is encouraged to use his or her strengths to achieve a common goal. Bad tech leads, on the other hand, can demotivate a team by failing to establish a central vision and by hoarding all the interesting work.

Many tech leads find themselves promoted into this role because they were either the most experienced or considered the best developer on the team. However, this may not be the best way to choose tech leads for the team.

Writing code does not develop leadership skills

Developers spend a majority of their time writing code. They read about new tools, algorithms and technologies and structure software to solve business problems, overcoming many technical hurdles in this process. Although developers work within teams, their focus is very much on what they produce at the keyboard.

When a developer is promoted to the tech lead role, he or she must suddenly draw on different skills, which may never have been needed as a developer. In his or her previous role, a developer could easily avoid being pulled into arguments between fellow coders by returning to the safety of his or her keyboard and taking the “it’s not my problem” stance.

A tech lead, however, cannot ignore these disagreements. If they do, the situation may never resolve itself – leading to endless arguments or a codebase that moves in different directions making it more difficult to add features over time.

A developer’s experience crafting code and designing algorithms does not prepare him or her for the unpredictable and highly emotional world of managing people. A tech lead requires skills that include coaching, influencing, facilitating, motivation and delegating, which brings us to another challenge for the expert developer.

The desire to ‘do’ competes with ‘enable’

Expert developers are recognised for their expertise because they have built up their ability to produce well-written code consistently and on a timely basis. They have honed their sense of good and poor code recognition, and are proud to write good code, whilst avoid working with poorly written code.

When the best developer is promoted to a tech lead role, he or she has to oversee and review the code produced by other developers on the team. If the tech lead was previously the best developer on the team, they might perceive the code written by others as suboptimal. They could explain why the code is poorly written, but they might think it faster if they simply rewrite it, or do the task themselves to begin with.

Although the tech lead’s thinking may hold true in the short term, this attitude has other side effects. Given additional responsibilities, the tech lead’s time cannot possibly scale to cover all the work the entire team must produce. Also, it signals to other team members that the tech lead does not trust them, and can have the effect of making other developers feel disempowered.

Though initially difficult, the expert developer promoted to a tech lead role needs to reframe the way that he or she adds value to the team. He or she must stop viewing the solution as writing the best code themselves, and instead take a longer-term view of enabling others in the team, so that they too can write code just as well as they can. With this broader focus, the tech lead can make the team collectively more effective.

Writing code is not the same as designing a system

Developers spend their day designing code to meet some need. However, ‘clean code’ is not valuable until it is deployed and made available to end customers, which requires a different mindset – instead of developing code, developers must develop systems.

In many organisations, developers do not know the configuration of their production environment, making wrong assumptions about the code they write. This is often the difference between a system that works, and a usable and performant system that works.

The ‘works-on-my-machine’ anti-pattern is common for great developers, but tech leads have to think in terms of the overall system, and not just the code.

The good news

Although organisations must be wary about promoting the best expert developers to the tech lead role, not all is lost. Good developers can make great tech leads but organisations must recognize that tech leads also require a set of complementary skills.

The activities and situations most developers work in day-to-day do little to prepare them for leading a team, enabling and encouraging team members, or focusing on the overall system.

Good tech leads require a good amount of technical knowledge, but they do not necessarily need to be the best. They need to be good enough that the team respects the tech lead technically, but they will probably draw more on their leadership skills day-to-day than their technical skills.

Organisations can cultivate the next generation of tech leads by sending potential tech leads on leadership courses and highlighting the skills they must build in their new role.

In this article, I’m sharing 7 tips that can help you become a senior software developer. Keep reading.

Complete control over at least one programming language

Skill in the Programming language is a key to get success in the software development field. If you want to build a successful career in software engineering, then you must obtain mastery over at least one programming language because this will help you to gain good control over the software development process.

Java, Python, C++, etc., are some of the programming languages which will be very useful for you. It is generally not recommended that you must learn 3 to 4 languages simultaneously at a time because it will make everything messy rather you must try to focus on any one language in which you have an interest and get mastery over it, then go for the next.

Switching to the next language will be much easier once you get good control over a particular programming language.

Knowledge of Data Structure and Algorithm

A good software engineer should be well versed in data structures and algorithms because if you don’t have these skills, then it will not be possible for you to write any real-world application. So you must have proficiency in data structure and algorithm.

An algorithm is defined as a set of steps to be followed to perform a specific task or to solve a particular problem. An algorithm forms the basis of every programming code and plays a pivotal role in software development.

Knowledge of basic structure like an array, map, linked list, etc., helps in the proper functioning of the program and leads to the development of robust quality software. A good programmer must have all knowledge of them. If you want to become successful in programming, then you must obtain command over them as early as possible.

Skill Enhancement in the Software Field

You must try to supplement your study by visiting coding sites like StackOverflow and other websites like CodinGame and CodeWars, which offer thousands of problems, and if you put your efforts into solving them, you can improve your skills and obtain greater capability in your work. However, it demands a lot of hard work and patience to bring improvement.

You need to explore open-source code more and more. For this, you need to find projects that you think are interesting and look into their source code to know about how the developers accomplished the task.

In addition, you must try to find developers who are experienced and ask them for help in the form of feedback on your project, etc. This step will not only help you to enhance your knowledge and skills but also bring your mistakes into the limelight. It will help you to check your performance parameters and maintaining your qualities.

Reading of Code Made by Experts

Just like reading books enhance the knowledge of a person, in a similar pattern, if you read the code written by some expert software engineers, then there is a high chance that your skills in software development will improve a lot and help you to get excellence in this area.

Reading code also helps to boost your analytical thinking, which leads to the generation of new innovative ideas. Further, you must try to read a more diverse set of projects to get an extensive understanding of the range of your work. Once you enter this field, you must always try to be a constant learner. If you become a good learner, then you will be able to solve critical problems more efficiently.

Learning Cloud Platform

Cloud is another area open for a Software engineer to learn to get advanced competency in the field of Software development these days. Nowadays, almost all companies irrespective of their sizes and domains are shifting their environments into Cloud due to cost-saving and better scalability, which simply means that sooner or later, you need to work in a cloud environment.

There are many popular Cloud platforms like Amazon Web Service (AWS), Google Cloud Platform (GCP) or Microsoft Azure, etc. If you get knowledge of them, then it will help you to take one step forward against your competitors. However, you are not required to learn all of them, and in fact, learning one of them will give you a fair idea about others.

Understanding of Networking Basics

With the advancement of technological development, we see that the entire world is interconnected nowadays, and this is all possible due to networking. You can find computer networks all over, starting from home where you use your WIFI and across many devices in school, college, and offices, which uses Local Area Network (LAN) to the Internet.

Even most of the applications developing these days are not standalone applications but are based on the client-server model. This entire model makes use of networking because under this, the client computer is connected to the server to give instructions, and the connected server does the task as desired by the client. This is all possible due to networking.

That is why networking is now interlinked with software development. Hence, to compete in changing environment, you must have a good knowledge and understanding of networking.

Advance Excel skill and use of Text Editor

Advance knowledge of Excel is one of the important skills that a programmer must have in their armor. The reason is that Excel provides many useful features and functionalities that can help you to perform sophisticated data analysis. It also helps you to keep track of the progress, data reconciliation, data quality check, easy comparison, sorting, filtering, etc., and many more.

Besides, it is extremely user-friendly and easy to work with. So It is highly recommended that you must have advanced knowledge of Excel to generate more efficiency in your work.

A good Text Editor is also very helpful to the Software Engineer. This tool helps in the easy development of program code. It has lots of features which can make the work of Software development and writing code very easy. So it is very beneficial for you if you work on any good text editor of your choice.

Older Posts »

Categories