You don't need to be an 'investor' to invest in Singletrack: 6 days left: 95% of target - Find out more
As much as it may seem, I'd like to hope this doesn't end up sounding like a plea for help. I could post this on a more related board but at the end of the day, riders probably provide more realistic feedback :).
I took a job last year as a software engineer even though I'm not of that background, the plan is to learn on the job (was hired on this basis, I'm not supposed to know anything).
Since starting I've never felt like I've been getting the hang of it. I can't see my skills developing and I'm constantly failing to deliver anything each sprint (I've had the same ticket for about 7 weeks now, whilst those around me consistently deliver to the project). I've raised this with my management and they seem rather care free about the situation. The response is always 'it will come'. But day after day I can't help but feel that each day is just a losing battle to try to get anything done. I'd like to say I try my damndest and try and do self learning at home as well as at work.
Has anyone else started from scratch in software? I can see that its a complex job, but is there a timeframe you can possibly put on something like this at which you can just say 'Yeh, I tried, its obviously not for me'.
What are you struggling with?
Following the logic? The language? General concepts? Design?
It can be difficult to learn something while trying to deliver at the same time, learning often involves going back to the start rather than going forwards. If its a new language I usually try to buy a book and read it when I have time as I always find that better than online learning. Books usually seen better thought out
If they are not providing any training then if I were you I'd consider approaching your project manager, expressing your concerns and asking for a mentor or programming buddy. (Not unusual, especially with new engineers).
I switched from civil engineering to software development over a period of years, id say I was productive from the start but I had a lot of very good help.
I do think that programming is something you get or you don't.
What languages and frameworks are you using? You will need to know the syntax (if/loops/logical operators) the libraries (how to read write to astream) and the frameworks - these depend on the language for Java for example they would be JUint,Hibernate, Spring/EE
You would also benefit from knowing about the design patterns for the manages you are working with. Try and find a book that covers the GoF patterns with examples in your language.
There are on line resources that can help such as Linda.com and stack overflow. You can also try reddits such as r/programming and r/lean programming where you can work through problems and be critically assess.
As you mention sprints I'll assumed you are using Scrum, many you could suggest doing some pair programming - this is another agile methodology here you and a coworker said a computer to work on a problem together.
And based on STW it helps if you are called Graham
If they are not providing any training then if I were you I'd consider approaching your project manager, expressing your concerns and asking for a mentor or programming buddy
This +1, I can see it being quite a frustrating experience if you are getting no support. It would be odd really, given the situation you describe for your team/management to not expect to need to provide this. Even with experience, other peoples input is a useful thing.
As for how long to know if you will "get it" - I think I've been doing to too long to be able to offer an opinion!
Ignore him. He's the early Alpha release.
TheBrick - Member
What are you struggling with?Following the logic? The language? General concepts? Design?
I don't think I have much problem with the language I use. It seems to be translating what is expected from my particular implementation into actual software.
I think a very general process for me is: Try and progress, fail, try and fix + try and attempt different solutions to the failure (seems to be where the bulk of my time goes), give up and ask for help, someone comes and shows me where I was wrong, then instantly hit another problem and the cycle continues. I just don't seem to get much success/satisfaction.
leffeboy - Member
It can be difficult to learn something while trying to deliver at the same time, learning often involves going back to the start rather than going forwards. If its a new language I usually try to buy a book and read it when I have time as I always find that better than online learning. Books usually seen better thought out
I don't know whether I can apply this properly, though thanks for the help. I think I'm lacking in software design principles (e.g. do this this way because its the most efficient), as opposed to 'you can do this this way in Java'.
As you mention sprints I'll assumed you are using Scrum, many you could suggest doing some pair programming - this is another agile methodology here you and a coworker said a computer to work on a problem together.
I think this would most definitely help me, my colleagues are quite old school with their development but I think I need to try and push this next sprint planning.
GrahamA - Member
And based on STW it helps if you are called Graham
I was expecting that response to be from GrahamX.
Yes, it doesn't have to be actual pair 'programming' either - the phases of the process that most benefit from the pairing are
1. the analysis of the problem and the break down into 'use cases'
2. the determination of what to test and how to test those use cases - preferably automatically
3. the solving of any problems/bugs
If you are struggling because you don't know enough of the product/frameworks you are using/design principles involved/toolset used, then you could suggest that you pair up with people to participate in one of the above activities instead of coding, which should help you contribute to the deliverables, whilst you catch up on areas that you are less familiar with.
If you don't feel that you have enough domain knowledge to contribute then consider a temporary transfer to QA (it is always useful to have less familiar people who are likely to 'break' stuff) or even to operations, to learn more about the domain.
At most a ticket should probably take 3 weeks - depending on your sprint cycle - and taking 7 means either that you are really struggling or the ticket scope is too large and/or not defined enough. A non-requirements ticket will normally only cover a use-case which should be well defined.
We've found pairing to really help people learn on a project, that being said I do have a team who can be good at sharing information and skills when the time comes.
The advice here is as good as you'll get elsewhere, raise to your Scrum master/PM and try as much as you can yourself then get help. It is also important to learn from your colleagues as opposed to asking the same question over and over.
When it comes to coding approach problems - StackOverflow is your friend 🙂
I will say, having done some teaching in CS in a university (and from my own experience) some people "get it" and some people don't. Those that don't can muddle through, but it's always a struggle for them.
What are you doing to learn? Just your job, or trying your own projects on the side?
I interview a fair few engineers (both grads and senior level), and I firmly believe that it is something that requires a particular mindset to be competent at.
If you are struggling to learn a language, framework, syntax or design pattern, that is something that will come. If you struggle to produce logical, simple code, then I'm afraid that you will always struggle.
If you don't love the coding, then modern software development has many other roles (such as testers, project managers, business analysts) which all used to be the domain of the software engineer and have now become seperate roles. They are all equally rewarding career paths.
interview a fair few engineers (both grads and senior level), and I firmly believe that it is something that requires a particular mindset to be competent at.
I think some people call it a "spectrum". 😉
I think some people call it a "spectrum".
Pretty much, hence one of the reasons that there are far more male programmers than female.
And yes, that includes me 😀
They are all equally rewarding career paths.
!!!
what does
a = a + 1
mean to you ?
apparently those that think it looks wrong (as it it blatantly not true) will probably have problems with programming.
I think the mindset is being able to break down a problem into small steps. This is something that people do in everyday life as much as in development. My wife for example has never written any code but she approaches any practical challenge in exactly the right way.
I'd say that fixing problems in existing code (or making small enhancements) is quite hard for an absolute beginner, because you have to understand how the existing system works. If it's badly written or complicated, you'll be in a heap of trouble; if there's little useful documentation it'll be worse. I'd be asking for some basic courses on software design, rather than language use specifically.
When faced with having to figure out how a complicated system works and fix issues, I reach for my imaginary deerstalker hat and become Sherlock Holmes. You have to deduce what's happening from the evidence available, just like Holmes. It's not easy, for sure, but being methodical and logical helps.
apparently those that think it looks wrong (as it it blatantly not true) will probably have problems with programming.
Not sure that's true - those who think it looks wrong probably have a maths background - once you tell them that = is an assignment operator it makes sense!
A better test would be to ask someone to give instructions on how to make a cup of tea, and be as specific as possible... see what they come up with. But this doesn't help the OP as that's all about designing code, not fixing someone else's.
Re pair programming - the experienced person has to have the right mindset to teach well, which is another aptitude altogether 🙂
"spectrum" - ha ha I think I worked with the bulk of those in my day!!
pair programming can work but if the guys are old school they may not get it, or have the mindset, or be at the right time (I know I felt a bit like that sometimes).
Get one little thing working - in isolation, in a test bed - and program the hell out of that - make it work, make it fail, make it faster, more readable, more reliable - then move on. With mentor of course. I learnt a lot from a couple of very helpful guys. Some were as above a bit fearsome though.
Callum (sorry, Graham...)
oh, and I find myself in a testing (as in program test) role as much as dev. these days, coming from a dev. background I find it helps, and the same skills and er attributes can work equally well for testing as for coding..
I suppose that's where TDD has its strengths, possibly.
So what are you actually doing? I think you mentioned Java, but perhaps if you could add a bit more detail we could give you a few pointers about things you could read up on?
I suppose that's where TDD has its strengths, possibly.
TDD has lots of strengths but one of them is obviously emphasizing the test aspect (!).
I heard a colleague trying to come up with a 'definition of done' guide for when a ticket is complete, and there was a peer code review in it.
I pointed out that this didn't fit with the agile/XP model of TDD, where the importance is defining tests that cover the functionality required for the next deliverable, and then you make all the tests work in time for the next deliverable.
If something has to be coded up in a non-optimal way to meet the deliverable then it doesn't matter - the importance is that the test works.
Once delivered you then refactor to make the code better, before you build on it again - otherwise the entropy of the system will increase.
If a code review at the end pointed out that you had done it the wrong way or that the code was iffy, then so what? Any code review is at the start of the next phase, probably with your pair as you design it.
A lot of the value of a system is then in the tests, which are often named in a way that makes assertions about how the system works, which also helps document the system. Newbies can see the assertions, and also trace through the tests to see how their solution was implemented.
it sounds like you have a very nice boss.
you say:
I can't see my skills developing
it's easy to fall into this mindset when your head is not in a good place.
are you making the same mistakes today as you were a year ago? - or are you making brand new mistakes?
if it's the latter, that sounds just like my experience of coding.
(almost, the more I learn, the more complicated the mistakes)
A Pluralsight membership is a good option - the more expensive opton lets you download courses to your tablet which you can watch on the commute (unless you are driving...) and has exercise files.
One advantage is being able to flick back and rewatch portions, in case you don't get it first time or weren't concentrating fully.
They are only really a higher level overview - you would need to read a book to get more indepth knowledge, but as long as you practise what you have watched then they are good.
@TurnerGuy, I agree entirely on the "tests are the specification" aspect of TDD - I suppose I was trying to get across that if you are analytical, and have come from a coding background, then testing - and writing tests - becomes almost second nature, the picky aspect at least - what happens if I do *this*, boundary cases, really esoteric scenarios.
I suspect a good deal of lawyers are "spectrum" as well - I certainly suspect my dad was - all those legal special cases, it's like code in words 🙂
I had to sit an aptitude test when I got my first software development job. Out of a room of 100 people only 2 people passed the test.
Have you been on any basic software design courses i.e. language independent?
I agree entirely on the "tests are the specification" aspect of TDD
Only if the design part is done well.. like many of these ideas it only works well if everything else is done perfectly.. which is rarely the case in my experience.. and you end up wasting a lot of time.. in my experience problems with projects are rarely due to implementation bugs in specific sections of code.
Remember that projects vary enormously. A lot of these methodologies seem to come from the USA where the working practice and even the scale of projects is quite different. People seem to read the blurb and decide XYZ is the best way of doing things, but what's best varies hugely depending on the project situation. There is no 'best', only the right way in the right project at the right time. That's why there are so many approaches.
But this is a hijack, so please accept my apologies 🙂
Out of a room of 100 people only 2 people passed the test.
here's my aptitude test - does this code work, and if not why not (ignore any syntactic errors) :
[pre]
public class Node
{
public int _value;
public Node _nextNode;
}
public class Test
{
public static Node insertNodeInSortedSingleLinkedList(Node firstNodeInList,
Node newNode)
{
Node currentNode = firstNodeInList;
Node previousNode = null;
while (currentNode._value < newNode._value)
{
previousNode = currentNode;
currentNode = currentNode._nextNode;
}
previousNode._nextNode = newNode;
newNode._nextNode = currentNode;
return firstNodeInList;
}
}
[/pre]
Seems to work pretty well for me, rooted out some major bluffer in the interviews (knew all the terms, etc) and highlighted some pretty quiet and/or inexperienced people that turned out to be really good.
Answers about using frameworks to do this stuff are missing the point. I normally make sure the candidate is comfortable with what a singly linked list is and also what the problem is - find the point in the list at which to insert the node (as the list is sorted - as in the method name) and then adjust the links.
Pretty reasonable test I'd say*. Bit easier than FizzBuzz 😀
(* I know the answer but as I'm not the target audience I won't spoil the fun for my own ego just yet)
Not keen on that kind of aptitude test TurnerGuy. You don't need a roomful of nitpicking geeks on a dev team 🙂
When asked if a piece of code works, my first instinct is to run it and see. If it doesn't, I put breakpoints or diagnostics in until I narrow it down to a certain point. I don't see the point in stepping through it in my head when the computer can do it a lot faster and more reliably.
I'm very good at finding and fixing defects in real life, so it's frustrated to be rejected based on what is essentially purism.
The answer is pretty simple and logical - you test for a median case and two limits - beginning of list and end of list.
You can also consider an empty list and a null newNode if you want.
So you can choose suitable values and walk through the code to prove or disprove it, or you can just identify the unit tests you would write to test the method.
So it's still a pretty relevant question imho.
Not keen on that kind of aptitude test TurnerGuy. You don't need a roomful of nitpicking geeks on a dev teamWhen asked if a piece of code works, my first instinct is to run it and see. If it doesn't, I put breakpoints or diagnostics in until I narrow it down to a certain point. I don't see the point in stepping through it in my head when the computer can do it a lot faster and more reliably.
Yep, seen your comments before and pretty sure you wouldn't get my selection...
Nit picking geeks is completely not the point of the question.
Identifying people who seem scared of getting their hands dirty and walking through some pretty simple code is - as has happened here 🙂
Walking through framework code - and in walking through disassembled code - to find a problem is a lot more of an ask.
And in the modern world if you find a piece of code that doesn't work you then identify why your tests didn't highlight it, fix the test, and then fix the code. Otherwise someone else could break it again in the future and you wouldn't catch it at build time.
I put breakpoints or diagnostics in until I narrow it down to a certain point. I don't see the point in stepping through it in my head when the computer can do it a lot faster and more reliably.
Depends on the job. We do a lot of embedded stuff and don't always have access to fancy-schmancy breakpoints, debug output and the like.
Plus a test like that shows you know where the likely failure points are. Depending on the inputs you could run through that code in your IDE (or unit test) and it would work just fine, but by reading it I found an error faster than it takes my IDE to launch. 😀
here's my aptitude test - does this code work, and if not why not (ignore any syntactic errors) :
Before looking at the code, I'd want to know what you mean by "work" and what the code is supposed to do. If it's a routine to translate French into Klingon then no, if fails quite catastrophically.
Yep, seen your comments before and pretty sure you wouldn't get my selection.
You think I'm not good at my job? Could it be that my approach is just different?
Identifying people who seem scared of getting their hands dirty and walking through some pretty simple code is - as has happened here
You would seem to be a worse interviewer than I am a developer 🙂
And in the modern world if you find a piece of code that doesn't work you then identify why your tests didn't highlight it, fix the test, and then fix the code
Aye, if you're working in an environment with a comprehensive set of unit tests, and IF the defect was caused by logic and missed by poor unit tests.. that's usually not the case in my area and experience. Defects in my line of work are usually caused by poor specification, analysis and communication. That line of work incidentally is Enterprise Java.. interested to know what yours is?
By the way, I've stepped through tons of code, I'm not afraid of it. I have decompiled code, stepped through it, found the line and emailed the vendor's support with a fix. However I've also found defects in products by deduction without seeing any code, which stumped everyone else. In fact it's my favourite part of the job. I love being brought in when no-one else can fix the problem, cos I always can 🙂
Before looking at the code, I'd want to know what you mean by "work" and what the code is supposed to do. If it's a routine to translate French into Klingon then no, if fails quite catastrophically.
it's in the method name...
You would seem to be a worse interviewer than I am a developer
if the candidate is struggling even after I have explained what the linked list is I then start walking through the median case, selecting values for the list and drawing it out, selecting a newNode value and inserting it into the list at the right place, with the links redrawn. etc.
If still no go I walk through the code for the median case, giving the candidate every chance to realise the need to test the edge conditions (beginning and end of test).
Basically as much hand holding as I can in case he is code-blind or suffering from some other interview-induced stress.
But some candidates just can't seem to cope with it - but if they are phased by this then how would they cope with the need to locate a bug quickly under pressure and produce a reliable fix...
I had one guy who seemed to talk the talk and know all the terms, etc, who then proceeded to tell me the variable names were poor and he would rename them to things like a1 and a2!
Sorry mol, but if you can't spot the fairly obvious flaw in what amounts to six lines of effective code then I wouldn't hire you either, because you may be a whizz at debugging in an IDE but how are you going to perform code reviews or write correct unit tests (both of which should, if done properly, spot the error).
I don't doubt you are good at [i]your[/i] job, but development practises vary so it's quite reasonable for TurnerGuy to say you wouldn't suit [i]his[/i] job.
who then proceeded to tell me the variable names were poor and he would rename them to things like a1 and a2!
It's faster you see, because the computery thing doesn't need to spend so much time reading. 😉
Sorry mol, but if you can't spot the fairly obvious flaw in what amounts to six lines of effective code then I wouldn't hire you either
I have deliberately not read it 🙂 I am saying that I don't like that kind of test. Of course if it's that easy then perhaps it's not so bad, I don't know.
it's quite reasonable for TurnerGuy to say you wouldn't suit his job
Possibly true yes. One thing I don't like is geek dogma.
it's in the method name...
You'd hire a developer who trusted the method name as a reliable means of determining what the method was supposed to do?
interested to know what yours is?
would have to hook out my cv to be precise but it would be approx 10 years C, 12 years C++, 6 years C# and some Java in there as well. Lot of async/multithreaded experience.
You'd hire a developer who trusted the method name as a reliable means of determining what the method was supposed to do?
He also gave a little potted description, much like you'd expect to see in a comment:
"find the point in the list at which to insert the node (as the list is sorted - as in the method name) and then adjust the links. "
Plus it is pretty obvious from the code what they are trying to do.
TG I mean what kind of systems etc? Enterprise, embedded, game, what?
You'd hire a developer who trusted the method name as a reliable means of determining what the method was supposed to do?
pedantic...
obviously if it didn't then there is scope for the candidate to point that out. However in the introduction to the problem I have explained what it is supposed to do anyway, confirming that the method name is correct.
I basically try to be as handholding as possible and give the candidate as much help as I can - the good cop/bad cop part of the interview comes later...
All I want the candidate to do is identify that he would test if for the median case and the two edge cases - simple logical thinking...
He also gave a little potted description, much like you'd expect to see in a comment:
Oh yeah. I've just failed the aptitude test for failing to read the question properly. (-:
[i]Has anyone else started from scratch in software? I can see that its a complex job, but is there a timeframe you can possibly put on something like this at which you can just say 'Yeh, I tried, its obviously not for me'. [/i]
I started from scratch, +30 y/o 🙂
I've been in IT since I left school and IMO there are some people who get it and some who don't, but the vast majority, get [b]some[/b] of it...
Also how old are you, because for many people their ability to learn something new diminishes with age - ie once in your 40's it drops off.
Aye, if you're working in an environment with a comprehensive set of unit test
Surely if you are working in an Enterprise Java environment, and environment which is tool rich, then it is a pretty big flaw if you have produced a system that isn't...
Surely if you are working in an Enterprise Java environment, and environment which is tool rich, then it is a pretty big flaw if you have produced a system that isn't
Depends on the project 🙂
On this one, if we'd spent the time producing comprehensive unit tests we'd have still had defects, but we'd have missed our deadline by months and incurred huge penalties. We only had time for basic unit testing.
All I want the candidate to do is identify that he would test if for the median case and the two edge cases - simple logical thinking...
Yeah, that's the problem isn't it. I don't really understand linked lists or the syntax around them, it's 20 years since I last did anything like this; but looking at it, I'd guess there may be an issue if the new node is the first in the list (as previousNode is null) or the last (as the while loop will _nextNode past the end of the list).
Am I anywhere near?
Am I anywhere near?
Yes, pretty much spot on I'd say. Two nasty null de-reference errors waiting to happen there.
Oh, that's brilliant. (the pic)
TG I mean what kind of systems etc? Enterprise, embedded, game, what?
At the moment it is a hosted 'messaging hub' - around 700 fund providers/distributors all passing STP messages to each other through us, using different (flavours of) protocols/transports.
Pretty simple design really. All in one of those hand-holding managed languages...
Previously various trading systems.
Complicated wise one nice component I wrote subscribed to reuters price feeds and also sniffed out new price 'chains', so registering them with the system and subscribing to them as the same time, so that was pretty heavily multi-threaded. Config guide I wrote was 55 pages long 🙂
Wrote a compete Fix engine at UBS as QuickFix wasn't around at the time - certified it with CME and others.
Many more things...
Java wise I wrote a JMS adapter for our system to bridge between our C# and a Sonic MQ system - carries 40% of our flow.
Also wrote a dummy exchange at UBS in Java - we called it the Black Market as the configuration allowed trading in Uzis and Cocaine 🙂
Most complicated big system I worked on was a a 3 tier distributed MM/FX trading system where the Kernel was (part) written by the Nick Hines, who was later the head of tech and MD at Thoughtworks (you must have read Martin Fowlers books...) - I later ported all the network layer from Netbios to TCP/IP and the kernel from OS/2 to Windows NT, and rewrote most of it in C++ instead of C.
As he says - once you had worked on that system, everything else is easy.
Is that enough context ?
Am I anywhere near?
yes, and I would have done my best to coax you to the point of those answers - I am not so worried about not knowing the language as that can be learnt easily later if needed.
As pointed out earlier - if you think in the right way and can identify that the edge conditions need testing in the above, then you could contribute usefully in a paired environment whilst picking up any tech skill needed on the side.
Ah yes.. trading and financial transactions.. that explains it.
On this one, if we'd spent the time producing comprehensive unit tests we'd have still had defects, but we'd have missed our deadline by months and incurred huge penalties. We only had time for basic unit testing.
that is completely wrong thinking - you really don't get how modern development is supposed to work.
Spending the investment on the tests up front has the massive benefit of producing a stable system fast.
Try ready the XP explained book for a flavor.
I produced a gateway for our Superstream offering a couple of years ago - we were late to the party but (the management) had committed ourselves to a group testing deadline, and the company that was going to supply the engine were trying to screw us for a shed-load of money.
One of our guys came up with realistic deadlines for writing our own gateway, but it was a long way past our deadline.
I stupidly said 'let me have a go' and ended up working 14-16 hour days, 7 days a week, for about 3 months.
Hit various nasty technical issues, like MS not supporting soap-with-attachments, required security protocols not supported, etc. Net Reflector to the rescue...
Obviously I was really tired towards the end, but I had arranged the database design and configuration file topology such that I could use nunit to orchestrate the integration tests allowing me to fire up several gateways within one test and test passing messages around and testing the message content.
If I hadn't have risked that investment there is no way I could have delivered anything stable, or with the required functionality. As I developed functionality the system remained stable as I would catch the errors I introduced because I was tired, or when I had to significantly refactor something to support new functionality.
I see this pattern repeatedly, in my work and others.
Using excuses like yours is a sackable offense in my book...
Loving that photo GrahamS!
@ OP : I've been in IT for 10 years now, mostly rising up through the ranks of Windows SysAdmins (pretty GUI, point 'n' click, etc). Never really [i]needed[/i] to learn a programming language, I could always understand sufficient (from examples, books) to get a task done.
Now I've moved into DevOps (Linux only), I have been required to learn - from scratch - a new language/framework (Chef / Vagrant) which is critical for my job.
I found a few different eBooks online, and only really got on with one - so purchased a physical copy to digest ( Learning Chef: A Guide to Configuration Management and Automation - by Taylor & Vargo).
Finding the right teaching materials that works for [b]you[/b] is key.
Good luck!
Ah yes.. trading and financial transactions.. that explains it.
wtf does that mean ?
that you don't have to have any technical depth if you work on EJB stuff ?
Has anyone else started from scratch in software? I can see that its a complex job, but is there a timeframe you can possibly put on something like this at which you can just say 'Yeh, I tried, its obviously not for me'.I started from scratch, +30 y/o
Same here - we were lucky as it has been a gradual introduction to what we have now, so we learnt 'from the ground' up, or from 'first principles'.
I feel privileged to have learnt from K&R, Stroustrup, Barbara Moo and Andrew Koenig, Jon Coplien, etc.
what doesa = a + 1
mean to you ?
Are we talking BASIC or C++ operator overloading?
Could be just about anything if the latter.
wtf does that mean ?
Well I've never worked in that area but it seems fairly low level with stringent performance requirements and a particularly high cost of failure, so a good place for nitpicking geeks.
If you are using high level products and tools, it's not that you don't need technical depth, but it's in a different area. What little code there is should be very simple and very obvious. The complexity comes with the interactions between various products and how they operate. There's a lot of subtlety and detail in the design, much less in the code.
It's faster you see, because the computery thing doesn't need to spend so much time reading.
You laugh, but I still write software the way I did when I was programming my Commodore 64, when that kind of thing mattered 😉
I can't even work out how my own code works, sometimes. This is perhaps why I'm better at building bikes.
that is completely wrong thinking - you really don't get how modern development is supposed to work.
The deadlines are imposed on us, we don't supply them.
Using excuses like yours is a sackable offense in my book...
And yet here I am, successful and capable. Good job we're not using the same book* eh? 🙂 We are on course to deliver, btw, and our system works. Despite the lack of comprehensive unit test coverage.
* for the reasons outlined above. Different areas require different books.
that explains it.
??
I've been a software engineer since 1997 and my background includes such varied things as oil industry applications, mobile phone network QoS, blood glucose meters, cash machines, automotive control, MRI scanners, cow monitoring(!), and secret squirrel shh-shh stuff.
I've been up and down the stack from high-level stuff (Business Objects, Oracle, SQL Server, OLAP, Java, Spring, AJAX, XML/XSD etc) through middleware stuff (AMQP, SOAP), and a lot of low-level stuff (microprocessors, embedded devices etc).
I think the test TG set is pretty reasonable.
[b]Edit[/b]: you've explained yourself while I was thinking about my CV 🙂
Well I've never worked in that area but it seems fairly low level with stringent performance requirements and a particularly high cost of failure, so a good place for nitpicking geeks.
Yep, a lot of the stuff I do is technical, safety critical and needs to meet stuff like FDA, MISRA, MilSpec, ISO standards.
Which may be why I see TG's side here.
I think the test TG set is pretty reasonable.
As said - it can work well, sometimes it doesn't.
If you haven't got time to create unit tests, what do you do? How do you meet that challenge?
That photo should be the interview test. Anyone who laughs gets it 🙂Oh, that's brilliant. (the pic)
Just to clarify - I'm not saying that TDD or unit testing is a bad idea. I'm saying that the best approach depends on the project and the situation.
Don't like the look of the while loop termination condition in TG's test 🙂
Got null pointer exception written all over it.
If you haven't got time to create unit tests, what do you do? How do you meet that challenge?
You can either spend time writing tests or time in maintenance trying to figure out bugs.
The latter tends to exceed the former.
If you [i]really[/i] can't test everything then you test at the boundaries/interfaces to make sure you can at least have some confidence in how it all hangs together. (plus that gives you some power to refactor)
You can either spend time writing tests or time in maintenance trying to figure out bugs.
The latter tends to exceed the former.
So you're given a fixed amount of time in which to complete a project. You don't tihnk it's enough - do you just refuse to do it?
Remember, I'm talking about comprehensive unit test suites. Functional and integration testing is still in.
So you're given a fixed amount of time in which to complete a project. You don't tihnk it's enough - do you just refuse to do it?
The Agile way is to sit down with the [url= https://www.mountaingoatsoftware.com/agile/scrum/product-owner ]Product Owner[/url] and decide which features or User Stories they want to ditch so you can hit the deadline.
The premise is basically that a system with the top 80% of the requested features that works 100% is a much better product than a system with 100% of the requested features that works 80% of the time.
The deadlines are imposed on us, we don't supply them.
and you write the unit tests to ensure that you meet the deadlines with a stable system, and also don't over-engineer the solution to the problem.
That is just such a poor excuse for someone who works a a world of supposedly good practice, such as Java and EJB.
Just about all of the modern testing toolsets were first available in the Java environment.
You are just kidding yourself. Spend the time on learning how to use these tools to make your life easier.
I have worked in a lot of institutions with unbelievable levels of incompetence (it seems investment banks value it...) so the fact that you continue to work in that antiquated way doesn't surprise me.
These test frameworks are successful because developers don't like testing, but in this case they are writing code to do the testing so that compensates.
Plus there is a level of sophistication in using these test, ioc, mocking frameworks that also appeals.
And lastly, as I said, the tests and the assertions in the good test names, are a good form of documentation and knowledge sharing.
If you haven't got time to create unit tests, what do you do? How do you meet that challenge?
IMO - unit tests can add some upfront cost to the timescales; however they are rarely in themselves a reason why timescales slip. Dev's don't always get the tests correct - anyone who claims to write bug free tests; might as well claim to write bug free code and be done with the tests after all 🙂
I'm not the biggest fan of TDD though; there are times when it's use is appropriate and times when it's not. And nothing puts off a competent developer from moving over to a TDD style of development than being evangelised at by a TDD-to-deather* who thinks anyone who doesn't do TDD is inferior. It's not a golden 'this will make your code good' saviour; and it can't replace intelligent people who can think carefully around a problem and create well structured; well thought out maintainable code.
*anyone who's worked in an agile environment will know the type
Sorry - this thread seems to have been derailed slightly !
Could you give us an example or two of something you are struggling with - maybe some mocked code / modified and an outline of what you are trying to achieve - I wouldn't expect you to copy and paste actual source code from your repository here - but if you can give us an idea we might be able to give some pointers* on how it could be approached ?
Steve
Plus there is a level of sophistication in using these test, ioc, mocking frameworks that also appeals.
This is another interesting aspect. If you know you will be unit testing stuff then it encourages lots of good healthy design/programming principles (loose coupling, IoC, [url= https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 ]SOLID[/url] etc) that make the resulting code better.
You are just kidding yourself. Spend the time on learning how to use these tools to make your life easier.
No, you are not understanding me.
I've written bloody thousands of unit tests too.
so the fact that you continue to work in that antiquated way doesn't surprise me
You just don't understand my point. I don't 'continue' to work in this way. I work the way that the project demands. Projects of which I am not in charge, incidentally.
Instead of denouncing me as incompetent, you perhaps should've asked me to explain myself and listened. Glad you're not my boss 🙂
I'm not the biggest fan of TDD though; there are times when it's use is appropriate and times when it's not.
Bingo.
a TDD-to-deather* ...*anyone who's worked in an agile environment will know the type
Yeah they are often seen name dropping all over the place 🙂
