Monday, 19 December 2011
Regarding "The Engineering Route to Accounting". The guts of the post is probably summarised by the sentence "Many people find themselves approving expense reports for people who do the work they enjoy doing, or used to enjoy doing. [i.e. engineering]".
I responded, and thought I may as well repost as I spent a fair bit of time composing it! As follows:
OK, I _somewhat_ agree that “by the time you have your degree, you have 5–10 years to go before, if you have any ambition, you end up a manager of some kind” – I would swap the word “any” for “a good amount of”, and I would add to the word “ambition” the words “competence”, “enthusiasm”, “empathy”, “confidence”, “integrity”, etc,. Not everyone is asked to lead, or manage.
I do not agree that “you don’t get to build anything, technicians do that … you only approve their expense reports …”. I think as a manager/leader, you are still building things, maybe just not in the same way an engineer would. Would Steve Jobs say he didn’t build the iPhone? Would Bill Gates say he didn’t build the Microsoft Corporation?
As an afterthought to this response I wrote:
... – my comment may come across as quite complacent.
So I should say that I agree leadership/management is not for everyone; it can be a burden, and it can be misused terribly.
I think your list of “What can you do if you want to avoid going into management/accounting?” is pretty spot-on John, nice one.
I hope if you stumble across this and have made the transition from engineering to management/leadership, that you find some of this useful.
Monday, 28 November 2011
Not specifically with SFTP, but other miscellaneous (non-HTTP) protocols.
I guess that this is an architectural misnomer. Technically, the WWW does not propagate anything but HTTP(S) (and whatever you choose to encapsulate within the HTTP protocol) - yes?
So if you were dealing with (for example) SOAP or RESTful web-services, putting "WWW" in the cloud thingy 'might' be appropriate, otherwise it's just the plain old internet.
Just putting it out there, mainly because I have not blogged anything for a little while...I bet the title of this post made you think it was about something much more interesting though, right?
Monday, 1 August 2011
Eclipse, Android Development Problem - "Error: Error generating final archive: Debug Certificate expired"
Wednesday, 27 July 2011
[Table("User", Schema = "dbo")]
public class User
public ActionResult Index()
string userName = Request.QueryString["userName"];
string password = Request.QueryString["password"];
_simpleListRepository = new SimpleListRepository();
var simpleLists = _simpleListRepository.GetSimpleLists(User.Identity.Name);
return View("Index", simpleLists);
else if (userName != null && password != null)
_simpleListRepository = new SimpleListRepository();
var simpleLists = _simpleListRepository.GetSimpleLists(userName, password);
var simpleListsDto = AutoMapper.Mapper.Map<IEnumerable<DataModel.Models.SimpleList>, IEnumerable<Models.SimpleListViewModel>>(simpleLists);
return Json(simpleLists, JsonRequestBehavior.AllowGet);
Unfortuantely AutoMapper uses Reflection.Emit, which is not allowed in a Medium Trust environment (i.e. my shared hosting web host).
There is an alternative out there called ValueInjector, which is not quite as complete-a-tool as AutoMapper as far as I can tell and has a bit of a steeper learning curve. Apparently it can be used in a Medium Trust environment:
I've reverted to a custom mapping implementation for the time being, since what I'm doing right now is not DTO-intensive. AutoMapper is great though and ValueInjector looks interesting.
======= EDIT - 2011-08-01 =======
Tuesday, 12 July 2011
Dr McKendry is a New Zealander who has built a successful career overseas and has basically come home and done a talk dissing the nation that launched him.
Original link: http://www.stuff.co.nz/technology/5264129/Kiwi-software-skills-shallow
(2): "Your Business: Timing Right for Software Success" (thanks Dad)
This is my uncle, talking about the successful SME that he has built over the past 15-to-20 years and his plans for it's future.
Original link: http://www.nzherald.co.nz/business/news/article.cfm?c_id=3&objectid=10737621
EDIT - 20131204:
Since I wrote this post - just about two years ago today - my thinking has changed (perhaps due to the business studies that I have taken over the past two years) and I do now sympathise with Dr McKendry's perspective more.
There is room for improvement in NZ business. The cost of complacency is high and growing.
Thursday, 19 May 2011
Monday, 25 April 2011
Book: Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and [...]
I found part two exceptionally enlightening – this is the first book/article that I've read which deals with the matter of managing software developers directly, from the point of view of a former/current programmer.
Part one (The Practice of Programming) contains a very useful series of four chapters entitled “Painless Functional Specifications” - again, fantastically simple ideas and solid reasoning as to why it's critical that (almost) any piece of software development should be preceded by the thought process and documentation phase that amounts to a functional specification. I would just about say that this series of articles (or something resembling it) is a must read for any developer. Too many developers (myself included at certain times in the past) in my opinion are all to willing to dive into coding ahead of putting the simplest of designs on paper – this process alone can reveal fundamental flaws in a plan. Joel goes so far as to recommend that developers take a simple course on practical writing, totally agree. Almost all of the other chapters in this section are brilliant and enlightening – certainly however “Painless Functional Specifications” stands out as gold IMO.
Parts three, four and five are not so well organised and start to devolve somewhat into (loose?) assemblies of blog postings; many of which are revealing and fascinating (especially IMO, where Joel makes comparisons to his experiences as a Program Manager at Microsoft). There's a few posting about .NET that are particularly intriguing.
Many of the articles in the book were written in the years ranging 1999-though-2004; a period of time that the .NET Framework was in it's beta manifestation or in v1.0 and v1.1. I find this section fascinating for two reasons. Firstly, Joel has recorded, like a time capsule, some of the ridiculous announcements and summaries of .NET that Microsoft first put out there. I remember at the time, as a student and emerging professional developer being simultaneously intrigued and baffled as to what the heck .NET actually was. Over a period of a couple of years the hype boiled down to an apps development framework that was more-or-less similar to Java. Some of the fantastically broad and meaningless spiels that Microsoft were using to describe .NET at the time made it seem of equivalent magnitude and significance to a manned mission to Mars or Skynet becoming self aware, without providing any detail whatsoever about what .NET actually was. I guess however a campaign that marketed .NET as “Microsoft's equivalent to Java” wouldn't go down to well with non-technical folk. Joel saw though the bollocks back then with crystal clarity. The other element of Joel's commentary of .NET that rang true was his questioning of the need to engage .NET seriously as a development platform, and the cost of rewriting existing code-bases to integrate with .NET. To do this is a costly venture that many businesses are still struggling with the practicality of today. I remember at the time, the organisation that I was working with was wary of .NET and the cost that it represented from a business perspective. Joel's writings from this era reflect the exact same sentiment. For myself, at this time I was a fledgling developer who has just realised what .NET was all about and was keen as to get stuck into it – this didn't help things, and eventually led to my departure from a good company (voluntarily!). I have gone on to become a strong and accomplished .NET developer, at the cost of an opportunity to be part of a great NZ success story. Them's the breaks I guess – I enjoy what I do regardless and am still on good terms with the company that provided me with my first break into the software development industry (they are my Aunty and Uncle – the company is Abtrac), and that's what counts I think. Besides, I have moved on to another NZ success story! In summary, Joel's critique on the turmoil that the introduction of the .NET Framework brought to the Microsoft software development community is in depth and, I think, heartfelt. I enjoyed it.
In summary, this is an extremely useful book that is written in a lively and humorous manner. Well worth a read for anyone who has anything to do with software development. And in my opinion, a must read for Microsoft software development leadership/management people.
Friday, 22 April 2011
Wednesday, 6 April 2011
Thursday, 17 February 2011
- Chapter addresses one of the key features of the Scrum methodology (e.g. the purpose of the SrumMaster).
- The chapter's introduction covers the overview of the concept and explains how the chapter will deal with it.
- Two or three section (the "body") take us through some strategically selected real world examples, including an analysis of each.
- A conclusion ties the chapter together, and ponders the various outcomes of the scenarios provided.
Wednesday, 9 February 2011
Book: The One Thing You Need to Know...About Great Managing, Great Leading, and Sustained Individual Success
Tuesday, 4 January 2011
- Separate the people from the problem
- Focus on interests not positions
- Invent options for mutual gain
- Insist on using objective criteria
I have a SVN repo on my local machine that I have been shoving stuff into since before I knew how to use revision control systems properly (...
It's been a while since I made a purely technical post... So, today I wanted to make a change to a Microsoft Team Foundation Server 20...
Another purely technical post on TFS... The scenario We wish to migrate code between branches that do not have a branch/merge relationsh...
As time goes on, the world is becoming more-and-more automated by software. This essentially also means that there is an exponentially growi...