Previous Next

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive










Reports to





Role Summary

Organize and supervise all of the administrative activities that facilitate the smooth running of the office. Supports company operations by maintaining office systems. This role is responsible for the organization and coordination of office operations, procedures and resources to facilitate organizational effectiveness and efficiency. The incumbent will also be responsible for managing the front office and customer care duties.


Duties and Responsibilities: 

  • Welcomes visitors by greeting them in person or on the telephone; answering or referring inquiries.

  • Update appointment calendars and schedule meetings/appointments.

  • Petty cash management.

  • Handling customer queries and directing them to the relevant party’s.

  • Build sustainable relationship of trust through open and interactive communication.

  • Provide accurate, valid and complete information by using the right methods/tools.

  • Keep records of customer interactions, process customer accounts and file documents.

  • Follow the right procedures, guidelines and policies while communicating courteously with customers by telephone, email, letter and face to face.

  • Resolves administrative problems by coordinating preparation of reports, analyzing data, and identifying solutions.

  • Maintains supplies inventory by checking stock to determine inventory level; anticipating needed supplies; placing and expediting orders for supplies; verifying receipt of supplies.

  • Maintains continuity among work teams by documenting and communicating actions, irregularities, and continuing needs.

  • Handling company logistics, staff travel, meeting preparation, car booking.

  • In charge of office cleanliness and preparation of office tea.

  • Any other duty as assigned.


  • Excellent command of verbal and written business English.

  • Attention to details and problem solving.

  • Strong organization and planning skills.

  • Good presentation skills.

  • Good time management skills

  • Customer oriented and ability to adapt & respond to diverse culture.


  • Diploma in Business Management.

  • Good knowledge of office software packages.

  • Clerical and accounting knowledge.

  • 2 years working experience in the same field.

  • A valid driver’s license is an added advantage.

send a mail to

Add a comment
Previous Next

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Oracle recently lost its attempt to use patent and copyright law to force Google to pay US$9 billion for using parts of its Java computer language. Nine billion dollars isn’t chump change, not even for Google, but despite the verdict against Oracle, I’d say Google is not the only winner.

The dispute between the two internet giants was whether Google had needed Oracle’s permission to use computer code called the Java API. The API, and therefore the legal issue, relates to some pretty technical details about how computer programs work – how the instructions programmers write are followed on different hardware devices and different software operating systems.

The outcome of the case, decided in parts by a judge, an appeals court and a jury, was that Google’s use of computer code didn’t violate Oracle’s patents, and that Oracle could copyright its code. However, the jury found that Google’s use did not violate the copyright restrictions because it significantly expanded on the existing copyrighted materials, an exception in law called “fair use.”

It is not only a victory for Google, which has done nothing wrong and need not pay Oracle any money. Programmers remain allowed to use a very popular programming language without fear of crippling legal penalties – which in turn benefits the public, who use apps and websites made with Java. And while technically the legal loser, Oracle also won in a way, because it will benefit from Java’s continued popularity.
What’s an API?

To understand the heart of the dispute, we first need to grasp what an Application Programming Interface (API) is and what it does for programmers. At its simplest, an API defines the specific details of how a program interacts with a computer’s operating system and the underlying hardware.

Computer manufacturers use a wide range of specific components: hard drives and memory storage units with different sizes, faster or slower processing chips, smaller and larger screens. They also choose different operating systems, such as Windows, the Macintosh OS X, and Linux – each of which is regularly upgraded with a new version.
Hoping to avoid nightmares: a Java programmer. Joonspoon, CC BY-SA

Each variation might handle basic functions differently – such as reading a file connecting to the internet, or drawing images on the screen. For a computer programmer, that is a nightmare. Nobody wants to write a program that works only on a Dell laptop with a 15-inch screen, a 500 GB hard drive, 4 GB of RAM, running Windows 10 – and no other computer. And nobody wants to write the extremely large number of slight variations to make sure a program works on every machine, either.

The API solves that problem for the programmer, handling the complicated and difficult details of exactly how any specific computer will act. That leaves programmers free to concentrate on what they want a computer program to do, without having to worry about precisely how. It’s better for the user, too. If she has (for example) Java installed on whatever computer she uses, programs written in Java will run.
Java itself

The Java API contains methods for everything from reading and writing a file, to drawing on a screen, to handling web security certificates. Without a functioning copy of the API, programs in Java are fundamentally broken. Clearly, therefore, he who controls the API controls the language.

Oracle, when it bought Sun Microsystems, bought the rights to Java and its API. The crux of the legal battle was how this control is exerted and how far it extends.

No one denied that Oracle has a valid copyright on the language and API specification. This is a good thing. It means I can’t just make a copy of Java, give it a name (like “Darjeeling”), and call it a new language that I own. Similarly, a company can’t change the API arbitrarily and still call it the Java API.
What did Google do?

When it released Android in 2008, Google added software and hardware development to its existing internet service business. If its products were going to succeed, they needed to be able to run lots of interesting programs. The easiest way to do ensure that was to make sure the new devices could understand at least one computer language that’s already widely used by programmers. Java is a natural choice.

The alternative would have been to create a new language, but that pathway is fraught with difficulties. Introducing a new language requires convincing programmers that it is worth using and giving them time and resources to learn the language.

Once Google decided on Java, it needed to connect Java programs to Android’s hardware and software – it needed a Java API for Android.
Sharing names for computer commands

Rather than commissioning Oracle to write it, Google wrote the software in-house, customizing it for cellphone hardware. For example, Bluetooth, touch-screen gestures and telephone calls are not handled in Oracle’s standard Java API; they are solely in Android-specific code.

However, to be sure Android devices could run existing Java software, Google wrote its Android Java with some of the same commands as Oracle’s version of Java. Both Android and Oracle support the methods that let programmers use the same files.newInputStream(filename) command to initiate the arcane and complex Java file-reading process.

Google didn’t copy the code Oracle had written for other hardware or software systems. It wrote all-new Android-specific instructions for devices to follow each command, but to help programmers, gave many common commands the same name Oracle used.

Oracle’s lawyers sharpened their knives and the battle was on. Could Google use the same names, even if the code they referred to was different?
The stakes were high

If Oracle had won, Java’s days as a primary programming language for Android – the world’s most popular smartphone system – were numbered. Very quickly, Google would have chosen a new language for Android programmers to use, and published a conversion tool to translate existing Java apps into the new language. Then it would have stopped supporting Java. (I suspect one of Oracle’s competitors would have offered Google excellent licensing terms to choose another language.)

Programmers would have lost. The tools to write code for Android would have been, at a bare minimum, more expensive and less flexible. The public would have lost, because new and interesting apps would both be more expensive and released less frequently.

Finally, Oracle would have lost because programming in Java would no longer be a viable option for a major market. Computer languages compete for popularity, so fewer programmers would choose to program in Java, reducing the pool of people who were comfortable and competent in Java. Instead they would choose others, like Python or Ruby. With fewer people working in Java, Oracle’s primary way of making money from it (creating Java-based computer systems that can be expanded by third-party developers) would slowly decline.

Instead, while Oracle doesn’t get $9 billion from Google, the programming community – and those of us who use apps and websites every day – gets to keep using an important tool, without fear of a similarly large lawsuit in the future.




Add a comment

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

It's unbelievable to me that a company would pay a developer $60-$100k in salary, yet cripple him or her with terrible working conditions and crusty hand-me-down hardware. This makes no business sense whatsoever. And yet I see it all the time. It's shocking how many companies still don't provide software developers with the essential things they need to succeed.

I propose we adopt a Programmer's Bill of Rights, protecting the rights of programmers by preventing companies from denying them the fundamentals they need to be successful.

The Bill of Rights

Every programmer shall have two monitors

With the crashing prices of LCDs and the ubiquity of dual-output video cards, you'd be crazy to limit your developers to a single screen. The productivity benefits of doubling your desktop are well documented by now. If you want to maximize developer productivity, make sure each developer has two monitors.

Every programmer shall have a fast PC

Developers are required to run a lot of software to get their jobs done: development environments, database engines, web servers, virtual machines, and so forth. Running all this software requires a fast PC with lots of memory. The faster a developer's PC is, the faster they can cycle through debug and compile cycles. You'd be foolish to pay the extortionist prices for the extreme top of the current performance heap-- but always make sure you're buying near the top end. Outfit your developers with fast PCs that have lots of memory. Time spent staring at a progress bar is wasted time.

Every programmer shall have their choice of mouse and keyboard

In college, I ran a painting business. Every painter I hired had to buy their own brushes. This was one of the first things I learned. Throwing a standard brush at new painters didn't work. The "company" brushes were quickly neglected and degenerated into a state of disrepair. But painters who bought their own brushes took care of them. Painters who bought their own brushes learned to appreciate the difference between the professional $20 brush they owned and cheap disposable dollar store brushes. Having their own brush engendered a sense of enduring responsibility and craftsmanship. Programmers should have the same relationship with their mouse and keyboard-- they are the essential, workaday tools we use to practice our craft and should be treated as such.

Every programmer shall have a comfortable chair

Let's face it. We make our livings largely by sitting on our butts for 8 hours a day. Why not spend that 8 hours in a comfortable, well-designed chair? Give developers chairs that make sitting for 8 hours not just tolerable, but enjoyable. Sure, you hire developers primarily for their giant brains, but don't forget your developers' other assets.

Every programmer shall have a fast internet connection

Good programmers never write what they can steal. And the internet is the best conduit for stolen material ever invented. I'm all for books, but it's hard to imagine getting any work done without fast, responsive internet searches at my fingertips.

Every programmer shall have quiet working conditions

Programming requires focused mental concentration. Programmers cannot work effectively in an interrupt-driven environment. Make sure your working environment protects your programmers' flow state, otherwise they'll waste most of their time bouncing back and forth between distractions.

The few basic rights we're asking for are easy. They aren't extravagant demands. They're fundamental to the quality of work life for a software developer. If the company you work for isn't getting it right, making it right is neither expensive nor difficult. Demand your rights as a programmer! And remember: you can either change your company, or you can change your company.


Add a comment

User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active

I am impressed by the work that went into the M-Pesa Generation II platform iteration.

While it has grown in complexity, it covers almost all the permutations that make for a more efficient business operation where the speed of cash flow is key to sustaining many enterprises.

We have, in the past, explored how the banking sector was caught napping, as Safaricom extended its focus from peer-to-peer money movement to business transactions.

This has a number of benefits on SMEs, both in relation to trade between themselves and trade with large enterprises.

The benefits of M-Pesa Gen II are best realised when hinged onto valued added platforms such as Lipisha, KopoKopo, WezaTele and others, which via application programming interfaces (APIs), can marry data generated by a firm and automate certain processes with business owners avoiding the back-end admin complexity on the M-Pesa Gen II dashboards.

Payment collections

We have already been doing this for years, with players such as Cellulant, PesaPal, JamboPay among others having built sizable business providing payment aggregator services to a growing number of customers, most notably utility companies.

The M-Pesa Gen II value that is realised is on the consumer side, where LipaNaMpesa online is poised for an overhaul that will see a departure from the use of the Bonga PIN to complete online transactions.

The possibility of push payments opens up a new avenue of opportunities in differentiated M an E commerce user experiences. The result will be higher value baskets and lower cart abandonment rates, where most attrition happens at checkout.

Supplier payments

With a growing number of businesses having adopted the paybill and buy goods facilities, it is now possible to move payments directly from one paybill number to another in real-time.

Think of a scenario where the enterprise resource planning platform or customer relationship management system raises a payment request to a customer with all parameters already embedded and it only takes a simple maker — checker process to have the payments approved and moved with all authorisations and know-your-customer verified.

Access to capital

The only downside to the M-Pesa Gen II ecosystem that would apply to businesses is access to additional support services, core of which is access to loans.

Any growing business will at some point in their lifetime require this facility, whether it is to fuel growth or service a purchase order.


Add a comment
Previous Next

User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

A lot of people ask me things like ”What should I learn to get a programming job?” or ”How can I get a job as an engineer in Silicon Valley?”

Here’s an actual quote from last week:

So, I need some advice. I am 33 years old, and I need to get out of Support and in to at least DevOps if not full-stack development, but it’s so expensive. Any advice on what I should learn first?

The implication is usually which technology should you learn to get a job. As if your choice of technology is some kind of silver bullet.

Wanna know a dirty little secret? It doesn’t matter.

Any technology you’re likely to have heard of is a good pick. Does it have more than 10,000 results when you Google it? Then there are companies using it in production.

If companies are using it, then you can get a job doing it.

Ok, fine. There is a caveat: jobs are easier to get for technologies that are growing in popularity, and it’s harder to get a job in a technology that’s on its way out. So, maybe don’t pick FORTRAN or COBOL.

There’s another caveat — your choice of tech matters a lot more when you’re a programmer or developer than when you’re an engineer. That’s why engineers make $20,000 more than programmers on average.

Your real job as a software engineer isn’t to write code. It’s to translate hand-wavy business requirements into detailed specs that a computer can follow.

Your job is to ask questions and to find edge cases that the product people didn’t think of. Your job is to help operations define processes well enough to be automated.

Sure, you’ll write the code in the end, or maybe you’ll hand off the spec to a coder, but your real job is coming up with the spec. Even if it’s just in your head right before you write the code.

Don’t just learn a technology; learn how to solve problems with a technology.

The key here is that you have to play the long game. What interests you enough so that you can keep doing it for 10 years? It’s probably not a tech stack or a language, but a problem you want to solve.

Let’s say you work in support like that guy from the quote up top. What can you do to get a better job?

First, you can look at the job you already have. Are there problems you have or repetitive tasks you run into every day? You can probably automate those.

Start digging. Learn what you need to learn to solve your problem.

Then you look around. Are there any processes your team follows that are annoying? Processes that could be improved? Processes that you don’t use, but could make everyone’s lives better?

Then you can build something to make it easier. Start digging. Learn what you need. Someone who can take a loose problem and translate it into code is much more valuable than someone who can take specific instructions and write code.

Congratulations! You’re an engineer. You used technology to solve a real-world problem. And you didn’t even need anyone else to tell you the spec!

Not only is problem-oriented learning the most fun way to gain knowledge, it also teaches you all the other fringe skills that you need. Skills like turning fuzz into spec, Googling for solutions, digging into code to find bugs, talking to users, testing, and learning random new tech that’s handy. Learn all the things!

If you’re still stuck and don’t know which technology to use, go to HackerNews and find a “Who’s hiring” thread like this one. It’s a monthly collection of around 600–900 high quality jobs. Many of them list which technologies they use.

Read those threads. Count technology words. Pick the most popular 3. Learn them by solving a problem you have.

Be warned, though. That list changes completely every 2 or 3 years for libraries and frameworks and every 5 to 10 years for core technologies like languages, servers, and databases.

So don’t sweat the tech. Focus on learning to learn and solving problems. Be an engineer.



Add a comment

About Me

Oops...Almost forgot to say something about me. But anyway, I'm that guy, yule Msee, who'll sort out your techie issue and hails from the land of milk and honey. Not forgetting the bitter herbs too.

This is what am best at. Feel free to ask something. 

Latest Tweets