I’ve been working since 2011 and I’ve met different people from different industries. Professionalism not only inside the workplace, but also outside the physical office, is one of the most important traits and also one of the most difficult to master.
What I will write in this article is my personal experience. Please feel free to comment what you think, professionally. 🙂
First, I would like to say that I am not a role model. I am also in the process of practicing professionalism. It’s a broad term, but you can think of it as being polite as much as possible, and not letting your emotions control you especially in difficult situations. I know I still fail in that, so like I’ve said, I am still practicing.
I would like to start by criticizing myself. Here are my weaknesses, and I know some of you might relate.
Every business with an online presence has steps that a person must follow to become a customer. Whether people are buying your product or signing up for some other service, there will always be a certain number of steps they’ll have to take before they open their wallets and give you their hard-earned money.
The process by which you engage your prospect and turn them into a paying customer is called a sales funnel. A funnel exists at every one of your touch points—and one of the most valuable of these is your company’s blog.
Design is part art and part science. You’re applying your skills and knowledge to solve specific problems and, very often, to support the goals of your clients as well as your end users. At each stage of a project, designers should receive—and should welcome—thoughtful feedback that will help them arrive at an optimal design solution.
Being receptive to feedback, however, is its own challenge. You’re putting your own thought process and creativity up for critique, often by a mixture of fellow designers and laymen alike—yikes. To stay cool, you must learn to not take any reasonable critiques personally. To make it useful, you must be able to interpret and assess feedback and apply it strategically to your process.
As a developer and small business owner, I’ve had insights from both sides, I’ve worked as a remote developer and managed remote developers for different projects and with different teams.
In this post I’ll share some of my experiences in the hope that it will make life a bit easier for all parties in remote projects. When it comes to do’s and don’ts of remote team management, I tend to focus on “don’ts” – because unlike “do’s” they tend to apply to practically every team.
When entering the remote developers’ world, the biggest obstacle that managers must overcome is to change their mindset by accepting that the developer will not be in plain sight, and where they can manage and follow the work being done. This new paradigm requires businesses to implement a number of mechanisms to track progress and avoid a redundant workload. Such mechanisms will help both manager and developer be more productive, which is in everyone’s best interest.
To make it clear, all these mechanisms should not be used to control or micro-manage the employee.
Don’t Believe In Remote Team Myths And Misconceptions
Let’s take a look at the pros and cons of managing remote teams on a single project, by starting with communication.
Business has gone global, and the advent of vast, multinational organisations has created new challenges for millions of professionals around the world. The complex and intertwined nature of global teams demands a more thorough and thoughtful approach to internal communication.
In such organisations and teams, many individuals don’t have the luxury of working in familiar surroundings or speaking their native language. Teams working on the same project might be separated by oceans, rather than offices and cubicles. Team members come from different cultures and work across the globe.
One of the hardest things to do in software development is to determine how long and how much it will take to deliver a new software product. Should it be so hard? The answer is not straightforward.
Software costs estimation is inherently difficult, and humans are terribly bad at predicting absolute outcomes. No two projects are the same;each is unique in what it sets out to achieve, and unique in the myriad of parameters that form its existence. Often, what appears to be a simple problem on the surface is much harder or technically challenging to implement in reality. And, undoubtedly, there will be ‘unknowns’ with the project that can only be identified when they arise.
Additionally, no two people are the same, whether you’re a customer, a developer or a user. We come preloaded with our own set of knowledge, experiences, values, expectations, attitude to risk, and ability to adapt.
Writing good quality software is bread and butter for senior engineers; creating awesome software products can be a much harder endeavour, for all involved.
Delivering Awesome Software is a Balancing Act
But when it comes to software, understanding duration and cost are key in making strategic business decisions and this is true whether you’re creating a startup, realising a new business opportunity, or enabling your business to perform better. The timing, return on investment and benefit delivered can make, shake or break your business. You’ll be asking yourself: What do we get for our money? Can we predict our costs? What will it cost to create the product we want ? When can we launch? Will we get a quality product for our investment? Will it grow with our business? Will it deliver business value?
So, how do you go about estimating the size, duration and cost of a project? Let’s explore Agile project estimation and software development costs, and how we do it at Toptal.
We have a VB.NET application which was originally developed with the target framework as .NET Framework 4.5. However, because the client wants it to also run on Windows XP, we were forced it to change to .NET Framework 4. The solution is in this link. Just follow the steps on the Workaround section. I also copied the steps below to save you time from opening another page.
However, of course, if the current program requires the features that .NET Framework 4.5 offers, then you have no other choice but to re-program to support Windows XP (if the client doesn’t want to upgrade their computers and is willing to pay again to support Windows XP).
The simplest workaround is to edit the modeling project file to ignore target framework version mismatches as follows:
1. Unload the modeling project by right clicking on it in Solution Explorer window and choosing Unload Project.
2. Open the project file into the editor by right clicking on it in Solution Explorer window and choosing Edit projectname.modelproj.
3. Add the following element inside the <Project> element:
You’re in charge of delivering your company’s latest and greatest initiative that’s going to change the face of “Widgets International” forever. It’s a software project that’ll engage and enthrall your customers, make your colleague’s lives easier, and make the company millions in revenue. There’s a great deal of anticipation, fervour, excitement, and expectation. You need to get it done as quickly as possible, so your business can start to reap the benefits. The future success of the company depends on you. All eyes are on you. You cannot fail.
At first, you’re thinking to yourself “awesome, I’m up for the challenge. Let’s get this thing done!”. You pause for a moment, step back, and think to yourself “okay, so how do we do this?”. You start to talk to your colleagues and peers. You spend time searching for best practice software development and project management techniques, but the options and approaches are countless. There are acronyms and methodologies aplenty. Notable ones rise to the top. Doubt creeps in. Which one should we use? How can I guarantee success? What if I make the wrong decisions?
When it comes to managing software projects, there’s a heady mix of options supported by a myriad of opinion. Voices from the corners of the room whisper “try doing it this way”, others shout “this is the only way to do it”, and the rest just whimper “don’t manage it at all, just get on with it”. In reality, all those voices speak some truth. But what’s important is working out what’s right for your needs, your team, your business, and your customers.