Whenever you want to start Solr or any other search or big data application, you need to have as prerequisite the Java Runtime Environment, known as JRE.
How do you find out if you have the JRE?
Open the command line and run
It was early 2006, and I had what most people would consider a perfect job.
I worked as a Developer Platform Evangelist for Microsoft Corporation, delivering labs worldwide to Microsoft Partners and teaching how to migrate applications to 64-bit computing. I was working as a contractor, commonly called a v-(dash) in the Redmond/Bellevue corporate lingo.
My life was great, and it was also great for my main employer. “Rent-a-geek” as I call it, is very profitable given the right customer, and we always delivered to Microsoft on time and on budget.
One week, I was in Silicon Valley, then London, India, Seattle, Sweden, Boston, the Netherlands, Korea, Building 20 (the old main campus training center), and the list goes on. If you are curious, you can take a glimpse of my globetrotting in my post, Road Warrior.
The usual joke with my fellow trainers was, “What continent are we in today?” We lived in an eternal state of jet lag, but who doesn’t want to travel the world, all expenses paid, while doing something you love? It was the perfect job.
Then I quit my job to go headfirst into entrepreneurship.
And it was the best thing I could have done in my life.
It all started when I received an email from an ex-Microsoft employee who was starting his own company and asked me to help him with a potential project he had. I traveled to Seattle and was interviewed by a project manager (although if you have worked at Microsoft Corporation, you might notice that everybody seems to be a project manager).
The interview went great, and the project was approved.
That same night, I got a “formal” proposal from a hotmail address. A very nice rate for a three month project. Three months! It seemed like a tough choice and a risky one as I had a perfect job, and I’d been working for more than five years with the company that gave me the opportunity to work with Microsoft.
On the other hand, I had an offer for a short term contract that might be extended and turn into something better… Or maybe not.
Did I mention that, in my home country of Costa Rica, severance packages are mandatory and pretty high, unless you quit? It wasn’t an offer to start a company; it was a leap of faith to do a project, and if it worked we could take it to the next level.
I also had a hunch that this guy may not be the best choice. I ignored it.
What I learned: A hunch or gut feeling is your subconscious detecting a pattern that you can’t yet explain. Listen to it, but consider all factors as sometimes making the wrong choice can be good for you as well.
And I did it anyway. I picked up the phone, called the Human Resources department, and told them I was leaving.
Did I fear failure? Of course, but not enough to hold me back.
I also learned: To move ahead in life, you need to take action. John Sonmez said it very nicely in his Soft Skills book. If you start moving, it is easier to correct your course because you will have momentum.
Sometimes, you overthink too much, commonly called analysis paralysis, and opportunities pass you by. More than opportunities, life passes by, and you may wake up one day and regret everything you had an opportunity for and your own inaction.
Human resources tried their best to keep me in the company. Just as an interesting note, I’d been asking for a raise for a while, and they always said no. They were probably very confident that no one would leave the perfect job. They offered me heaven and earth, including doublingmy salary. That actually made me want to leave even more as it just reinforced how valuable I really was to them.
I sent in my resignation letter that same day.
It was a very direct and friendly Dear Company, I quit. Thanks a lot! letter. I still had a good relationship with them, so no bridge was burned. I was counting on it in case my contract was not renewed after three months, forcing me to crawl back with my tail between my legs to ask for a job at half my leaving salary.
Something I learned: Leverage is really powerful. You might be in a position where you are 100% sure you are being downplayed, but if you don’t hold enough bargaining chips, you might not come out with flying colors out of the negotiation. I am not saying you should quit to get a raise, but it has worked for me twice in my life.
And a word of advice: You have to be also very careful of not falling completely on the other end of the spectrum. Some people believe they deserve more than what they have earned. I’ve seen this trend especially with very young developers who think they will land a job at Facebook or Google right after graduation and make several hundred thousand a year.
You first need to work hard to reap the benefits. You need to earn it first.
And then my adventure began at age 26. I took a plane straight from Boston to Seattle without going back home to Costa Rica. All the time that I was traveling, I was using a corporate credit card, which I had to send back.
I only had $300 in my wallet and a $500 limit on my personal credit card. Finances were tight! I was young and totally used to swiping my corporate credit card and sending an expense report. This was a totally different experience as I was on my own.
I landed in Seattle and rented a car for a week (goodbye $500 limit on the credit card) and stayed for the first few days in a $29-a-night room near the Seattle airport. In theory—cross my fingers—I was going to get a cash advance from the new project and then get all the details sorted out.
About one week later, I got a $1000 cash advance, and soon after, all legal and financial details got sorted out. I could finally move into a shared apartment near Lake Sammamish in Redmond, about two miles from Building 120 where I was going to provide my rent-a-geek services in Microsoft’s main campus.
The cheap hotel was one hour away, but it is impossible to get anything cheap in the Bellevue/Redmond area.
What I learned: Sometimes getting started means you have to take a chance or two, and you will probably have to make sacrifices and compromises. Measure your risks, take action, and hope for the best.
I started working with Microsoft InfoSec, helping secure high business impact information. This was the three month project. It went well so I got another project, this time with Microsoft Consulting Services creating a SharePoint portal for CEOs and business people. I participated in a few more projects until, one day, I had a talk with the person who hired me.
At this point, I was providing consulting services on a one-project-at-a-time fashion, but he got me thinking: what if I went back to Costa Rica, and we started a company together? It sounded like a good opportunity to scale and get the company to grow. We were going to be business partners.
What I hoped for: For this job, I got paid per hour worked. Creating and scaling a company (even at small scale) means getting people to work for you and getting paid for the hours they work, not only your hours. And I knew that I wanted to create my own company.
It was another opportunity, so I took it. Without telling anyone, I booked a flight back home. I remember getting to my parents place to say hi, and they asked me with a very surprised face, “What happened?”
Nothing happened. I just took a chance to create something bigger.
A few months later, I bought a house, and it was still empty; thus it became the first company office. Two floors, three bedrooms. I lived in one bedroom, and the other two became offices.
In a stroke of luck, I had two friends who quit their job recently, and they were working on their own dream—game design—but needed work to support their initiative. So they joined as well, and one of them is the best developer I know. He was known as TOC, or table of contents, as he always had the answer for your question. I still admire his skills to this day and hope to get the opportunity to work with him again.
We started to scale.
My now business partner who lived in Seattle was in charge of selling, managing US financials, and getting contracts. I was in charge of delivering, hiring, Costa Rican finances, legal work, dealing with bureaucracy, programming, project managing, pre-sales, delivering, presentations, demos, and pretty much anything required to grow the company.
I was basically the jack-of-all-trades swiss-army-knife guy for a while. In fact, I hired an assistant until we hit the 12 employee mark and an office manager at the 20 mark. The office stayed at my house until we had 8 employees. I took the “he lives at work” phrase literally. Even days when I had parties at home, I always had to remind my guests not to use the servers to place food or beverages!
What I experienced: Unless you are a funded or backed up startup, it usually means that you may have to do all kinds of work. I was president, janitor, and everything in between.
The company kept growing, projects were delivered, and we kept hiring. It was quite a challenge, more than I am sure my business partner ever realized. We had a couple of problems.
Our first problem was that we were a small startup company where the office was in the 26-year-old president’s house in a third-world country ,and we were providing services to Microsoft Corporation. If I brought in someone for an interview, it may sound a little bit farfetched. If we were providing services to one of the biggest companies in the world, shouldn’t we also be in a fancy office?
People tend to forget how some big companies start in a garage. When you are getting started, it is critical that you plan ahead and save as much money as possible. Contracts and payments from customers may delay, but payroll must never be late. You should never ask your employees to wait for their paycheck!
Something we did right: If you keep your burn rate low, it gives you more runway to scale and adapt. Extra cash means being able to hire employees before you need them, allowing you to train them and get them up to speed instead of hiring them when there is an urgency and throwing them to the wolves to fend for themselves.
So many projects fail because people are not trained properly, and that’s why online training is so important, as Pluralsight can indicate.
But the first problem did not come alone. I ran face first into Costa Rican culture. In my home country, the employee mentality is rooted deep down in most people. Entrepreneurship is not the most common way to go.
Instead, everyone wants to get a job, work their hours, get a paycheck, rinse, wash, and repeat. When I was hiring, I had to inspire people into joining this small company that would grow and do great things! Come join me! You can work on world class, bleading edge SharePoint or Dynamics CRM projects!
Whenever I was doing an interview, if I liked the prospect, I had to switch hats and sell him or her the idea that we were what they needed to get ahead in life. It was tiring, but I did a very good job as I hired some great guys.
What I learned: If you inspire people, you can get them to work for more than just a paycheck. They can join you in a quest.
I also had to pull a few Houdini’s from time to time. Two weeks before we got our first real office, we received an email that a Microsoft Director of ISV Marketing and the CEO of a Microsoft Partner were in town and wanted to see the office. Crap! Which office? The unfinished one or my house full of cables and servers?
Also, being young, I had two big, off-roading, vintage Land Rover cars with no windows and an oversized, lifted Dodge Ram that was in no way fit for carrying around a couple of execs. I solved this problem with flying colors by:
As a side note, Costa Rica used to be big on coffee and tourism, but now it has evolved into technology and call centers. After my initial failure, one of my next ventures includes owning a small call center, and my US customer is delighted with our level of service!
What I learned: Do the best you can with the resources at hand. You will be impressed at what you can do with some imagination and careful planning.
Time went by, and that’s when I realized how I made a mistake.
When we decided to open a company in Costa Rica, we never discussed what was my percentage of ownership. We talked about ranges but we never decided an exact amount, and worst of all, we did not put it clearly in writing.
You see, when we started, it was all very fast, so we started under my Costa Rican company with an aim to create a new and fresh company once the startup took off. This could’ve been potentially disastrous to me if the startup failed as debts and employees were solely my responsibility.
As a real world example, one of my college professors started a game development company with some people from California, and when the company failed, he was personally liable for all debts, which he will probably have to work for 150 years to repay.
Luckily for me, that’s not what happened, but it could’ve ruined my life early in my twenties.
What I learned: Just like in the story of the chicken and the pig, be careful if you are committed while others are just involved. Take risks, but calculated risks. Share financial responsibilities with the others involved, and always make sure you know what the worst case scenario can be.
When it came time to take it to the next level of creating a fresh new company, that’s when it bit me in my behind. As the percentage of ownership was not clear, I couldn’t negotiate more than 5%, when I was personally responsible for the development success.
I am horrible at sales, but without my development lead, the company would not have grown the same way. If you need some help in estimating your percentages, there is a great method called “The Founder’s Pie” that I recommend you take a look at.
What I learned: You need to put everything clearly in writing as early as possible. You need to think of any possible outcomes and be in a position that you are comfortable with. My grandfather was a very prominent politician, and he used to say, “I trust you, but sign here first.” Sadly, I failed to follow his advice.
Something else I learned: Don’t ask for too much, but don’t undervalue yourself. That’s the part I always used to fail at. I usually undervalued myself too much. And yes, it is hard to estimate what you are worth.
But how am I so sure of my value? It is very simple.
I already had a few difference of opinions with my business partner, but the one I think was the trigger of me leaving was that, in a Starbucks in Bellevue circa 2008, we negotiated what was going to be my end of year bonus as a partner in the company if we reached a certain amount of sales.
Our agreement was clear to me. He offered three bonus levels based on company performance. Given that I trusted him, we didn’t put in writing the exact scenarios with amounts. I flew back home hoping for the big paycheck next year when we met our objectives.
As you probably are already expecting to read, when the year was over, we met and exceeded the quota, but my partner used the “we need to save cash” excuse to avoid paying me what I was owed.
He knew the number, he knew I was right, but in an episode of undervaluing myself, I accepted only 10% of what I earned in all rights.
But it wasn’t the crisis. Now that we were profitable, I think greed took over, and he realized that he didn’t want to share the profits with a 20-something even though I was the reason the company flew.
I later found out this was his third attempt at creating a company; the previous two failed.
So I decided this was the end. It was Friday morning, and we were having a heated conversation. I just told him, “Find someone else,” and hung up.
This was probably the most stressful couple of days for this guy since I just hung up and never took any more calls from him, being as upset as I was. And even though I was the owner of only 5% of the company, I had unlimited power as president of the company—and did I mention we had a quarter of a million dollars in cash in the bank?
With this money and current contracts, my full bonus was not that significant. The story could be totally different for everyone involved, but it wasn’t. As I left the building, I just logged into the online bank manager, paid myself the last two weeks salary, and took off. I didn’t take a cent more, not even what I was rightfully owed.
Word of advice: Be careful with money. I could’ve taken my bonus and severance, but that would’ve probably ended up in a legal battle and I did not want to take it to that level.
My business partner flew from Seattle, and negotiations were very sour. I still owned the domain and access to a lot of things that he didn’t even have. If he didn’t get everything I had from the company, it could be badly affected.
But this is not only a company.
It was a group of 24 hardworking individuals and their families. If I did something to hurt the company, I would also be hurting them. I ended up negotiating with one of my initial hires and gave up everything for a fraction of what my shares were worth. It was a big loss for me, not only in terms of money but also because I loved the people I worked with in Costa Rica.
What I did: I chose to lose to avoid affecting those I cared for. Don’t be evil. Karma will take care of you later in life, so don’t be the one causing damage. And always keep a cool head and avoid your impulses. You are a master of those words that you keep but slave of those that you say.
This was me starting from scratch again, just like that day I took a plane to Seattle to stay in a $29-dollar-a-night hotel. However, my situation was different now since I was engaged. I was on my own then, but not now.
I left the company on February 13, just one day before Valentine’s Day, and I was going to get married in 4 months. All preparations were ready for the wedding, but now being “jobless” and really tired of the drama was totally different than 2.5 years ago when I was excited to start a new adventure.
What I learned: When you are down, it is time to pick yourself up, shake your shirt, roll up your sleeves, and move forward. And so I started my new journey.
I mentioned before how I thought I was one of the main driving factors for the company’s growth. Why am I so sure? As soon as I left the company, it slowly started to downsize even though it had some of the best developers I’ve worked with. The company went from 24 employees down to 3 after about 4 years, at which time it was salvaged (acquired is a more friendly term) by another company.
So the reason it was moving forward was simple: I led the company to deliver results. Remember, delivering matters.
And so I started the next phase of my life at 29. It took me a day and a half to find a contract, not a job, and I have moved forward since then. I became a Pluralsight author and an author for Syncfusion Succinctly Series; run my own blog; own a small Support Center; created several cloud applications (success in progress, as I call them); have spoken at several conferences and meetups, including Microsoft’s SharePoint Conference, Atlassian Summit; and have been working as a consultant on multimillion dollar enterprise search projects with Apache Solr and FAST in addition to other areas like JIRA Agile, and Microsoft technologies.
Life has been great, and I am thoroughly enjoying every step of the way. I am working on things that I love, and it keeps getting better. If I think about it, had I not made the mistake of leaving my perfect job that spring of 2006, I would not have experienced all the adventures that I’ve had and would probably be working for the same company from 8 to 5 on a different project.
This mistake taught me how to run a company, and more importantly, it taught me what I want to be in my life.
Let me finish by adding a few more things that I have learned along the way:
Since the day I failed I have been working hard day and night to create my dream. Yes, everybody dreams, but only those who take action, make a plan, and move forward get ahead.
Be positive. There is a sea of opportunities out there but only for those willing to devote themselves entirely to making them happen.
This post originally appeared in: https://simpleprogrammer.com/failing-at-entrepreneurship-while-you-are-young-is-great/
You only have 24 hours a day…1,440 minutes…86,400 seconds. At first glance, this may seem like a lot.
But it is not.
There is a very limited supply of time, and it can be your friend or your enemy. And you get to choose if you are in control of your time, or if you let others control it.
That is why you need to Protect Your Productive Time.
But why? Why do you need to protect your time? And how do you do it? Let me tell you.
I am a .NET developer who is very passionate about enterprise search, primarily with Apache Solr. And this is great because I’ve spent the last few months of my life building the search API library for one of the Big Four auditing firms. It is a huge project, with hundreds of developers, and my library is only a very small piece in comparison to the rest, but it is a very important piece none-the-less.
And while working here, one of the things that I’ve noticed is how programmers have a tendency to give estimates that are not too accurate. Why does this seem to be a recurring issue?
Well, there are the endless meetings that they don’t account for in their estimates. There’s their own overconfidence — or ego estimates as I like to call them — and a tendency to assume features are simpler than they really are. Also, most people need a “warm up” period in the morning to get into the zone or “flow,” but then they have constant interruptions. If you want to learn more about getting in the productivity zone, I recommend Mihaly Csikszentmihalyi’s book Flow. It’s a classic and a must read.
Going back to estimates, let’s say for example that you estimate a task will take 40 hours, so just in case, you overestimate and say it will take 60 hours. This won’t work. Why? One good reason is that the next 20 hours might be filled with another 10 hours of meetings and interruptions. Just think about it for a minute. How many times a day (or hour) do you get someone that comes to your desk and says “Hey, do you have a minute?” and in some cases without even letting you answer, they sit down or put a laptop on your desk and start explaining what they need.
So let’s go back to the original question. Are you still going to be able to be done in time?
The answer is usually no.
So what I observed is that some people couldn’t function properly in this environment and couldn’t deliver what they promised when they promised.
I delivered what I promised.
With very little bugs (I can’t lie. I had bugs!).
Was it because of my technical prowess?
Not really. I am a decent developer (and can proudly say a Pluralsight author, Syncfusion author, passionate about Search, speaker, presenter, and trainer among a few other things), but nothing out of the ordinary. There are some developers that I know who are way better than me technically, but I can beat them by a mile in terms of delivery.
Here’s the “secret sauce”:
I did three things:
And I was very aware of the first two, but not too much of the third one, which now that I am fully conscious of its importance, I put it as a priority in my day to day work.
When and how did it become very evident to me? Here is the exact moment.
So, there I was one day minding my own business, heads down in Visual Studio, when Brent (one of the testers) approaches me and asks if I have time to review a bug and explain. It was a good moment — that’s what I thought — so I said yes. So he then looks to his side and about 3 cubicles down he signals a thumbs up to Radhika, another very nice tester, to which she smiles and with a face like a kid on a christmas morning says “yaaaaay”.
And then it hit me.
I had been protecting my time by managing all interruptions in a way in which I could focus on working and then schedule time for other people’s needs later. This might sound very simple, but it wasn’t. Everyone has their own deliverables for a specific date and time. And as much as you would like, their deliverables are their top priority, not yours.
And the better you are, the more time people take away from you. I have a friend who peers call “Table of Contents” because he knows everything. How much time do you think he spends working on his deliverables vs. fixing issues on other people’s deliverables? The answer is simple. Most of his time is spent helping others, and he has to work until late at night to finish his stuff, while the developer he helped goes home at 5 pm.
To add insult to injury, top developers usually get more work assigned. It kind-of makes sense from a management perspective. If you have a developer who is very productive, assign them more work and overall the project will benefit from higher productivity. The problem is that this is just short term thinking. As you squeeze out every last possible drop of code from a top notch developer, the end result will usually be a burned out developer or a resignation letter. Some managers don’t even seem to care. Burned out? Get another contractor or employee, rinse, wash and repeat. But this is a discussion for another post.
Let’s get back to time. Does it sound familiar that others come to your desk asking for your time? Do you have to help them the minute they arrive because “it is urgent”? Or, “C’mon man, it is only 5 minutes”?
What most human beings forget or don’t know is that the human brain requires concentration and focus, especially for activities like coding or design. Context switching breaks your process, which means that you need time to get back into your thought process. I am not an expert, but I heard that from any interruption you need at least 15 minutes to refocus and keep working. So a 1 minute interruption in reality can be 16 minutes that you will never get back. That’s why John Sonmez asks people not to message him while he is focused at work.
In my humble opinion, that is not a good deal for you.
Do you just put on your noise cancelling headphones and a big “Do Not Disturb” sign in front of you and code away?
It is not that simple either.
Unless you are a one man army product development unit, or your work is totally isolated from everyone else’s, then you are a necessary and useful component of your team’s development, and there is an intricate set of dependencies that cannot be ignored.
So what should you do? Let me tell you what I do and a few more tips that I have learned while out on the field.
If you consider how much time it takes for a human being to read 259 emails and respond to them, then he would spend all of his day just reading and replying without having any time to do any of his work.
I assume some of you already did the math, and in his specific case, he got an email almost every 2 minutes in average.
Yes, his was an extreme case. I’ve noticed that the higher you are in the “food chain,” the people have a tendency to add you to the thread. The developer can later claim “Ian was copied,” and that can get him out of trouble (or at least the developer thinks it will).
The same advice goes for email. While email is very important, your objective as a developer is to deliver working code within budget and on time. So please do not forget about email, but don’t make it priority #1 above your deliverables.
Remember, responding emails can keep you from getting fired, but delivering top notch quality code can get you promoted or a raise if you play your cards right.
I recommend you schedule email-dedicated times, and let your peers know so they have a better expectation of when you will be replying.
Okay. So at this point, we have covered two of the biggest distractors, IM and email. But what about the “hey do you have a minute?” cases where someone sits next to you and expects you to jump head first into their need.
Don’t get me wrong. I do it from time to time. It is an impulse. You need something and someone else has an answer. The impulse grows the more desperate you are.
Here is an example from a few months ago. I had already about an hour — that felt like an eternity — trying to modify a dependency injection scenario where I couldn’t get the bloody thing to work, and I knew that both of my team members, Sandeep and Satish, who were sitting quietly in their cubicles across from me, could definitively help. First of all, I was trying to get it done by myself. Just asking for help at the tiniest issue is not good. As a developer, I get paid to deliver, which involves finding solutions to problems that I run into in the process.
I had it almost sorted out. There was something that I was missing. When I decided it was time to get help, I did interrupt Satish, but I did in what I believe was a nicer way, not being abusive of their time.
I waited a bit for a time when I believed it was okay to ask for help, which was after his phone rang and he hung up. So I approached him and said “Hi Satish, I have a problem with IoC. Would you be able to help me when you get a chance.” I didn’t take my laptop with me either, because that would be applying pressure.
He said: “Yes I can, please give me 15 minutes.” About 20 minutes later, he told me he could help. And indeed there was something I missed, I corrected the error, continued development, and was able to check in the feature a bit later.
I did interrupt his work stream, but in such a way that he commanded his time. I asked for his help, but on his terms, whenever he felt it was a good time.
As I said, there are dependencies that can’t be ignored, but the trick is to be respectful of other’s time and expect the same.
IM, email, and one on one help can destroy your productivity, but they are more manageable than the next level of interruptions that can wreak havoc on your productive time: meetings.
Meetings are a double-edged sword. They are an absolute must in some cases, but a complete waste of time in others. And it may be difficult to know in which direction it is going to go. So let’s take it one step at a time with a real world scenario.
I participated in a large Agile project. In such a case, there are multiple teams that have different focused responsibilities. At a general level, you have the business people coming up with the specs, which then flow to the designers, who then pass it along to the architect team, development, testing, and deployment. The process is a bit more complex than this, and it is called Daikibo or Agile at scale, but you get the general idea.
In such an environment, it is of utmost importance that there is fluid communication and that every team down the stream understands fully what needs to be done.
Thus, we have meetings. Granted that specific issues can be followed up via emails, work items or IM’d, but sometimes a meeting is required to — as the cliché says — “get everyone on the same page.”
I give kudos to a well-run and organized meeting that has a very clear objective, which is met, and only the right people are involved.
Does this happen often? No, not really.
Meetings are abused continuously to levels that make my Outlook cringe in pain! I’ve already blogged a few times about this in Pluralsight, and on my personal blog about how to improve meetings and what hurts your meetings.
Sometimes I’ve felt as if we’ve had meeting inception. In some of the projects I have participated, it feels like we have meetings to plan for meetings! Eternal déjà vu. A glitch in the Matrix?
Increasing your meeting’s productivity is a topic that I intend to cover very soon in a different post, but for now, the general recommendation that I have for you is to minimize attending meetings to only when strictly required, by those that have something of value to add to the meeting, and at times that do not interrupt those who need uninterrupted time to concentrate and work. An example is at the beginning of the day, around lunch time and near the end of the day.
This is a concept known as core working hours. I saw a team down the hall put up a sign that explains this very clearly: “Core working hours are from 9 am to 11:30 am. Please do not interrupt, and expect a delay on our responses.” How great can this be? 2.5 hours of uninterrupted work time. So much productivity behind a closed door!
At first it might be a bit hard to have a part of the team not responding to your emails right away, providing instant replies to your messages or attending back to back meetings. But there are some very clear benefits to this model.
First, makers will concentrate on delivering. Don’t you hate when there is a team member that has a high priority item that is urgent, they don’t finish, and when you ask them why they answer “because I’ve been in XYZ meetings and responding to my emails.” This drives me nuts!
But notice that I am not saying all developers do this. Only a few do, but you get a potential excuse out of the way. For the rest, they get time to concentrate and work.
Another benefit is that other team members, when they know that a person will not be available during a particular period of time, will get used to planning ahead and communicate using email or via comments in work items. It doesn’t matter that much which tracking system you use, but it does make a difference if you use one. In Simple Programmer, we use Trello, but I am a big fan of Jira as a work tracking system. So much so that I have two courses on Pluralsight on Agile, both with Scrum and Kanban.
A core working hours agreement will definitively allow team members to have time dedicated exclusively for working, and this is great. But, you do have to take it one level above, and this is the hardest one: getting each person to be as productive as they can be.
This is no simple feat in any way that you look at it, and it goes beyond what can be done at a team level because it needs to happen at an individual level.
For a person to reach a peak and optimum performance level, they need to be in the right conditions — core working hours being one that I want to convey — and in the right mindset.
How can this be achieved? There are multiple books and methods that can be learned to achieve maximum productivity. For example, Sonmez does it using the Pomodoro technique, which he covered in the Soft Skills book and released recently in a course on his productivity secrets.
But this is the topic of discussion for another post, which I believe will be touched on at length in many more Simple Programmer posts, as well as the book and recently released course.
What I wanted to focus on was how to set the right conditions in a work environment that will allow you to be ready for the next level of maximum productivity.
Let’s do a quick recap of what I presented:
And there you go, that is my advice. Protect Your Productive Time!
Thanks to John Sonmez for the opportunity to write in his blog. If you want to supercharge your carreer, follow him!
This post originally appeared in: https://simpleprogrammer.com/protect-productive-time/
The other day I needed to finish a task I had in one of my servers and needed to remote into one of my Cloudera QuickStart VMs to run a test while on a trip. So I installed TeamViewer to access it. Steps are simple:
# Click on Download TeamViewer link for RedHat, CentOS, Fedora, SUSE to get the rpm package from the downloads page
Open terminal and go to downloads directory
sudo yum localinstall teamviewer_12.0.71510.i686.rpm
And then start with
Or big change in our world?
I think that the answer can be all of the above. “Hype” you might be thinking? Well, here is the deal. Our world has changed in unimaginable ways. The amount of information created daily is reaching levels that just a few years ago would’ve been considered science fiction or even plain old crazy.
Lots and Lots of Data
To make it even more interesting, a lot of it is unstructured data. Which can be kind of a problem if we think about it, because the success of relational databases has taught a lot of us to think in a columnar and relational way.
And this is not bad… at all. It is nice to have all your data and metadata organized neatly. You can use select, join, where, group by and more to get what you need.
But the success of relational databases can also create a blind spot for many. Just a few days ago I was talking with the VP and cofounder of a company related to migrations and artificial intelligence software whose company has faced success (as well as a few failures or learning experiences) in several world class projects. They had lots of data that they obtain from their automated code conversion tools and what are they doing? They are normalizing it into a database.
I don’t think it is a bad approach, however it is not the one that I would take. Long story short, I would store the logs as is in their raw format and then use any of the available projects to analyse it in multiple ways, looking for key points, failures, trends and more. But what you do with the data is the topic of another post or a Pluralsight training. Let’s go back to our main point.
Mountains of data is being generated daily and the amount will just continue to -grow- explode.
Unstructured Data “Just Happens”
If you had to structure all your data, do you imagine what the cost would be? Just go ask your manager for an Oracle system and some servers to process all of your web server logs to put them in tables. The cost would be exorbitant.
And beside cost, sometimes you may not know the structure of your data. And that is one of the beautiful parts of Big Data. You can just store your logs in raw format and later come back and do your work, modelling your data in different ways. And what if you have too much data and the process is taking longer than expected?
Well, just add a few more servers and get the job done in parallel. Hadoop runs in commodity hardware, thus you can get many relatively inexpensive machines to work together and process your data according to your needs.
The Cloud and the Bar
And even better, remember “the cloud”! A few years ago if you were a startup and needed beefy power, you would need a lot of upfront cash to cover expenses. Now with AWS and Azure we have the possibility of turning a few virtual machines, get a cluster up and running, crunch the data, get the result, turn them off and only pay for the time you use.
And this change has lowered the entry bar for innovation. Now many brilliant ideas can be tested or theories can be analysed at a much lower cost, benefiting all man kind. For example, it is possible to run analysis on medical treatments to help cure cancer or many other diseases. Sometimes answers to hard questions lie right there in the data, they just need to be discovered.
Hype or Go Figure This Hadoop Thing Out
But what about hype? Let me make this clear, I don’t think Big Data is hype. I do think that there is a lot of hype around it and even though we are able to do great things with Big Data, the greater public does not yet fully understand what can be done and how so I have taken a personal mission to help developers and the public in general understand Big Data (and Search)
So then it is time to ask ourselves this question:
What Are My Choices for Getting Started with Big Data?
Here is a collection of some interesting or fun articles that I have found on Big Data
– 5 Reasons to Move to Big Data (and 1 Reason Why It Won’t Be Easy): gives an easy to understand set of selling points on why to adopt Big Data, but making it clear some of the issues you might face.
– The Most Practical Big Data Use Cases Of 2016: covers some interesting use cases of Big Data. Remember, Big Data is sexy!
– Why ‘Big Data’ Means Nothing Without ‘Little Data’: Little Data is regular performance metrics.
– Why Big Data is the new competitive advantage: provides good points on how Big Data can help give you an edge.
– Big Data: What is it and Why it Matters: goes straight to the point to explain the basics.
– Big Data Analytics: What is it and Why it Matters: explains what is Big Data Analytics.
I have been working with Solr for a while, mainly from the .NET world and I basically love it. I use SolrNet which I think it is a very mature and stable library. I was asked today if I have ever used SolrExpress and if I recommend it over SolrNet.
The short answer is no, I have not used it. Therefore I can’t give a facts based recommendation, but looking over the source code of both libraries it is my opinion that SolrNet is still more complete. So I still believe SolrNet to be a more sensible choice.
It is worth mentioning that is a biased point of view, as I have used SolrNet multiple times and it really has made my life a lot easier.
Having said that, besides using it several times, I have authored a few things around Solr and SolrNet and used it extensively. It works fine and I know it pretty well. It basically gets the job done, it is pretty mature and almost complete (pending SolrCloud and a few minor things like a breaking change on collation).
Some of the things I created
I created a Solr training for Pluralsight
Getting Started with Enterprise Search Using Apache Solr …
Search is one of the most misunderstood functionalities in the IT industry. Apache Solr brings high quality Enterprise Search to the masses.
And a SolrNet training for Pluralsight
I wrote a book for a company called SyncFusion for their Succinctly Series for Solr and SolrNet
I’ve also done internal trainings, presentations and webcasts on Solr + SolrNet
Learn How to Add Search to .NET with Solr & SolrNet …
Search is a functionality that most people take for granted while at the same time it is deeply misunderstood and usually poorly implemented. .NET
SolrNet does not have yet support for SolrCloud in the main repository, but there is one fork that already uses it but our current project does not use forks, only the main repository. If that is not a blocker for your customer, go ahead or like in our case, just use a load balancer for querying and a call to zookeeper api to get leader for indexing.
Hope this helps.
Yesterday I was coming back from the beautiful mountains of Monteverde in Costa Rica, feeling full of energy after a relaxing weekend. Monteverde is one of the most beautiful places I’ve been. Newsweek has declared Monteverde the world’s #14 Place to Remember Before it Disappears.”
Anyway, on the drive back I stop and decide to check my email, as usual, and I see a contact form from my blog so I decide to check it. This is what I found, a note from Robert Stevens: Read more!
Whenever you want to start Solr or any other search or big data application, you need to have as prerequisite the Java Runtime Environment, known as JRE.
How do you find out if you have the JRE?
Open the command line and run
I received a question today on stemming and multi language. Basically, “why do we need multiple fields in our Solr in different languages and how do I test multi language stemming?”.
First of all, let’s explain what stemming is. Stemming involves reducing words to their stem (or base or root) during indexing and querying in an effort to improve recall.
For example, if a document includes the following phrase “Xavier walked to work every morning from Westside Parkway” and a user searches for walk then the results will correctly include the document that has walk. Read more!
I was having a conversation today with a person that needed some help on teaching his PMs Agile. I had a very simple response, get them started by watching the excellent trainings available in Pluralsight.
So, the first time I told him was:
– Agile has proven a succesful methodology in software… when done right Read more!